Application Load Balancer - Elastic Load Balancing
Karte der RessourcenSubnetze für Ihren Load BalancerLoad-Balancer-SicherheitsgruppenLoad Balancer-StatusLoad Balancer-AttributeIP-AdresstypLoad Balancer-VerbindungenZonenübergreifendes Load BalancingLöschschutzDesynchroner MitigationsmodusBeibehalten der Host-HeaderAWS WAF

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.

Application Load Balancer

Ein Load Balancer dient als zentraler Kontaktpunkt für Clients. Clients senden Anforderungen an den Load Balancer, die dieser wiederum an Ziele wie z. B. EC2-Instances sendet. Zur Konfiguration Ihres Load Balancers erstellen Sie Zielgruppen und registrieren anschließend Ziele bei den Zielgruppen. Außerdem erzeugen Sie Listener für Verbindungsanforderungen von Clients und Listener-Regeln zum Weiterleiten von Anforderungen von Clients an Ziele in einer oder mehreren Zielgruppen.

Weitere Informationen finden Sie unter Funktionsweise von Elastic Load Balancing im Benutzerhandbuch für Elastic Load Balancing.

Inhalt

Visualisieren Sie Ihre Ressourcen mit der Ressourcenkarte

In der Ressourcenübersicht werden alle Ressourcen Ihres Load Balancers einschließlich der Beziehungen und Routingpfade zwischen ihnen in einem visuellen Format angezeigt.

Die folgenden Load Balancer-Ressourcen sind in der Ressourcenübersicht sichtbar:

  • Listener

  • Regeln

  • Zielgruppen

  • Targets (Ziele)

Sie können die Ressourcenübersicht verwenden, um die Architektur Ihres Load Balancers zu verstehen und zu sehen, wie viele Listener er hat, welche Regeln an welche Listener weiterleiten und welche Zielgruppen zu welchen Zielen weiterleiten.

Sie können die Ressourcenübersicht auch verwenden, um unerwünschte oder falsche Konfigurationen und fehlerhafte Ziele zu identifizieren. Sie können Ressourcen innerhalb der Ressourcenübersicht auswählen, z. B. Regeln, für einen Link zum Bearbeiten der Konfiguration für diese Ressourcen.

Um die Ressourcen Ihres Load Balancers zu visualisieren

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich Load Balancers aus.

  3. Wählen Sie den Load Balancer aus.

  4. Wählen Sie die Registerkarte Ressourcenkarte aus, um eine Visualisierung der Ressourcen anzuzeigen.

    In der Ressourcenübersicht navigieren

    • Zeigen Sie mit der Maus auf eine Ressourcenkachel oder wählen Sie sie aus, um die Beziehungen zwischen ihr und anderen Ressourcen hervorzuheben.

    • Wählen Sie eine Ressourcenkachel aus, um zusätzliche Details zu dieser Ressource anzuzeigen.

    • Wählen Sie einen Ressourcennamen in einer Kachel aus, um die Detailseite dieser Ressource aufzurufen.

  5. Aktivieren Sie „Ressourcendetails anzeigen“, um zusätzliche Informationen für alle Ressourcen anzuzeigen.

    • Regelbedingungen: Die Bedingungen für jede Regel.

    • Zusammenfassung des Gesundheitszustands der Zielgruppe: Die Anzahl der registrierten Ziele für jeden Gesundheitsstatus.

    • Zielgesundheitsstatus: Der aktuelle Gesundheitszustand und die Beschreibung des Ziels.

  6. (Optional) Wählen Sie „Fehlerhafte Zielkarte“ aus, um alle derzeit fehlerhaften Ziele und die ihnen zugewiesenen Ressourcen anzuzeigen.

  7. (Optional) Wenn Sie Exportieren auswählen, haben Sie die Möglichkeit, die aktuelle Ansicht der Ressourcenübersicht Ihres Application Load Balancers als PDF zu exportieren.

Subnetze für Ihren Load Balancer

Wenn Sie einen Application Load Balancer erstellen, müssen Sie die Zonen, die Ihre Ziele enthalten, aktivieren. Um eine Zone zu aktivieren, geben Sie ein Subnetz in der Zone an. Elastic Load Balancing erstellt in jeder Zone, die Sie angeben, einen Load-Balancer-Knoten.

Überlegungen

  • Ihr Load Balancer ist am effektivsten, wenn Sie dafür sorgen, dass jede aktivierte Zone mindestens ein registriertes Ziel hat.

  • Wenn Sie Ziele in einer Zone registrieren, aber die Zone nicht aktivieren, erhalten diese registrierten Ziele keinen Datenverkehr vom Load Balancer.

  • Wenn Sie mehrere Zonen für Ihren Load Balancer aktivieren, müssen die Zonen vom gleichen Typ sein. Sie können beispielsweise nicht sowohl eine Availability Zone als auch eine Local Zone aktivieren.

  • Sie können ein Subnetz angeben, das für Sie freigegeben wurde.

Application Load Balancer unterstützen die folgenden Arten von Subnetzen.

Availability-Zone-Subnetze

Sie müssen mindestens zwei Availability-Zone-Subnetze auswählen. Beachten Sie die folgenden Einschränkungen:

  • Jedes Subnetz muss einer anderen Availability Zone angehören.

  • Damit Ihr Load Balancer ordnungsgemäß skaliert werden kann, stellen Sie sicher, dass jedes Availability-Zone-Subnetz für Ihren Load Balancer über einen CIDR-Block mit mindestens einer /27-Bitmaske (z. B. 10.0.0.0/27) und über mindestens acht freie IP-Adressen pro Subnetz verfügt. Diese acht IP-Adressen sind erforderlich, damit der Load Balancer bei Bedarf skalieren kann. Ihr Load Balancer verwendet diese IP-Adressen zum Einrichten von Verbindungen mit den Zielen. Ohne sie könnte Ihr Application Load Balancer Schwierigkeiten beim Versuch haben, Knoten zu ersetzen. Das könnte dazu führen, dass er in den Fehlerstatus übergeht.

    Hinweis: Wenn einem Application-Load-Balancer-Subnetz beim Versuch der Skalierung die verwendbaren IP-Adressen ausgehen, wird der Application Load Balancer mit unzureichender Kapazität ausgeführt. Während dieser Zeit werden alte Knoten weiterhin Datenverkehr bereitstellen, aber der gescheiterte Skalierungsversuch kann zu 5xx-Fehlern oder Timeouts führen, wenn versucht wird, eine Verbindung herzustellen.

Local-Zone-Subnetze

Sie können ein oder mehrere Local-Zone-Subnetze angeben. Beachten Sie die folgenden Einschränkungen:

  • Sie können es nicht AWS WAF mit dem Load Balancer verwenden.

  • Sie können keine Lambda-Funktion als Ziel verwenden.

  • Sticky Sessions oder Application-Stickiness können nicht verwendet werden.

Outpost-Subnetze

Sie können ein einzelnes Outpost-Subnetz angeben. Beachten Sie die folgenden Einschränkungen:

  • Sie müssen ein Outpost in Ihrem On-Premises-Rechenzentrum installiert und konfiguriert haben. Sie müssen über eine zuverlässige Netzwerkverbindung zwischen Ihrem Outpost und der entsprechenden AWS -Region verfügen. Weitere Informationen finden Sie im AWS Outposts -Benutzerhandbuch.

  • Der Load Balancer benötigt zwei large-Instances auf dem Outpost für die Load-Balancer-Knoten. In der folgenden Tabelle sind die unterstützten Instance-Typen aufgeführt. Der Load Balancer skaliert nach Bedarf und ändert die Größe der Knoten jeweils um eine Größe (von large in xlarge, dann xlarge in 2xlarge und dann 2xlarge in 4xlarge). Wenn Sie nach der Skalierung der Knoten in die größte Instance-Größe zusätzliche Kapazität benötigen, fügt der Load Balancer 4xlarge-Instances als Load-Balancer-Knoten hinzu. Wenn Sie nicht genügend Instance-Kapazität oder verfügbare IP-Adressen haben, um den Load Balancer zu skalieren, meldet der Load Balancer ein Ereignis an AWS Health Dashboard und der Load-Balancer-Status ist active_impaired.

  • Sie können Ziele nach Instance-ID oder IP-Adresse registrieren. Wenn Sie Ziele in der AWS Region für den Außenposten registrieren, werden sie nicht verwendet.

  • Die folgenden Funktionen sind nicht verfügbar: Lambda-Funktionen als Ziele, AWS WAF -Integration, Sticky Sessions, Authentifizierungsunterstützung und Integration in AWS Global Accelerator.

Ein Application Load Balancer kann in c5/c5d-, m5/m5d- oder r5/r5d-Instances auf einem Outpost bereitgestellt werden. Die folgende Tabelle enthält die Größe und das EBS-Volumen pro Instance-Typ, die der Load Balancer auf einem Outpost verwenden kann:

Instance-Typ und Größe EBS-Volumen (GB)
c5/c5d
large 50
xlarge 50
2xlarge 50
4xlarge 100
m5/m5d
large 50
xlarge 50
2xlarge 100
4xlarge 100
r5/r5d
large 50
xlarge 100
2xlarge 100
4xlarge 100

Load-Balancer-Sicherheitsgruppen

Eine Sicherheitsgruppe agiert als Firewall, die den Datenverkehr steuert, der in und aus Ihrem Load Balancer zulässig ist. Sie können Ports und Protokolle festlegen, um den ein- und ausgehenden Datenverkehr zu ermöglichen.

Die Regeln für die Sicherheitsgruppen, die Ihrem Load Balancer zugeordnet sind, müssen den Datenverkehr in beiden Richtungen auf den Listener- und Zustandsprüfungs-Ports zulassen. Wenn Sie einen Listener zu einem Load Balancer hinzufügen oder den Zustandsprüfungs-Port für eine Zielgruppe aktualisieren, müssen Sie Ihre Sicherheitsgruppenregeln überprüfen, um sicherzustellen, dass sie den Datenverkehr auf dem neuen Port in beiden Richtungen zulassen. Weitere Informationen finden Sie unter Empfohlene Regeln.

Load Balancer-Status

Ein Load Balancer kann einen der folgenden Status aufweisen:

provisioning

Der Load Balancer ist eingerichtet.

active

Der Load Balancer ist vollständig eingerichtet und kann den Datenverkehr weiterleiten.

active_impaired

Der Load Balancer leitet den Datenverkehr weiter, verfügt aber nicht über die notwendigen Ressourcen für die Skalierung.

failed

Der Load Balancer konnte nicht eingerichtet werden.

Load Balancer-Attribute

Dies sind die Load Balancer-Attribute:

access_logs.s3.enabled

Gibt an, ob in Amazon S3 gespeicherte Zugriffsprotokolle aktiviert sind. Der Standardwert ist false.

access_logs.s3.bucket

Der Name des Amazon-S3-Buckets für die Zugriffsprotokolle. Dieses Attribut ist erforderlich, wenn Zugriffsprotokolle aktiviert sind. Weitere Informationen finden Sie unter Aktivieren der Zugriffsprotokolle.

access_logs.s3.prefix

Das Präfix für den Speicherort im Amazon-S3-Bucket.

client_keep_alive.seconds

Der Keepalive-Wert des Clients in Sekunden. Die Standardeinstellung ist 3600 Sekunden.

deletion_protection.enabled

Gibt an, ob der Löschschutz aktiviert ist. Der Standardwert ist false.

idle_timeout.timeout_seconds

Der Timeoutwert für die Leerlaufzeit in Sekunden. Standardmäßig ist ein Zeitraum von 60 Sekunden festgelegt.

ipv6.deny_all_igw_traffic

Sperrt den Zugriff des Internet-Gateways (IGW) auf den Load Balancer und verhindert so unbeabsichtigten Zugriff auf Ihren internen Load Balancer über ein Internet-Gateway. Es ist auf für mit dem Internet verbundenen Load Balancers auf false und für interne Load Balancers auf true eingestellt. Dieses Attribut verhindert nicht den Internetzugriff außerhalb von IGW (z. B. über Peering, Transit Gateway AWS Direct Connect, oder). AWS VPN

routing.http.desync_mitigation_mode

Legt fest, wie der Load Balancer Anforderungen verarbeitet, die ein Sicherheitsrisiko für Ihre Anwendung darstellen könnten. Die möglichen Werte sind monitor, defensive und strictest. Der Standardwert ist defensive.

routing.http.drop_invalid_header_fields.enabled

Gibt an, ob HTTP-Header mit ungültigen Header-Feldern vom Load Balancer entfernt (true) oder an Ziele weitergeleitet werden (false). Der Standardwert ist false. Elastic Load Balancing erfordert, dass gültige HTTP-Header-Namen dem regulären Ausdruck [-A-Za-z0-9]+ entsprechen, wie in der HTTP Field Name Registry beschrieben. Jeder Name besteht aus alphanumerischen Zeichen oder Bindestrichen. Wählen Sie true aus, wenn Sie möchten, dass HTTP-Header, die diesem Muster nicht entsprechen, aus Anforderungen entfernt werden sollen.

routing.http.preserve_host_header.enabled

Gibt an, ob der Application Load Balancer den Host-Header in der HTTP-Anforderung beibehalten und unverändert an das Ziel senden soll. Die möglichen Werte sind true und false. Der Standardwert ist false.

routing.http.x_amzn_tls_version_and_cipher_suite.enabled

Gibt an, ob die beiden Header (x-amzn-tls-version und x-amzn-tls-cipher-suite), die Informationen über die ausgehandelte TLS-Version und die Verschlüsselungssammlung enthalten, der Client-Anforderung hinzugefügt werden, bevor sie an das Ziel gesendet wird. Der x-amzn-tls-version-Header enthält Informationen über die mit dem Client ausgehandelte TLS-Protokollversion und der x-amzn-tls-cipher-suite-Header enthält Informationen über die mit dem Client ausgehandelte Verschlüsselungssammlung. Beide Header sind im OpenSSL-Format. Die möglichen Werte für dieses Attribut sind true und false. Der Standardwert ist false.

routing.http.xff_client_port.enabled

Zeigt an, ob der X-Forwarded-For-Header den Quellport beibehalten sollte, den der Client für die Verbindung mit dem Load Balancer verwendet hat. Die möglichen Werte sind true und false. Der Standardwert ist false.

routing.http.xff_header_processing.mode

Ermöglicht das Ändern, Beibehalten oder Entfernen der X-Forward-For-Header in der HTTP-Anforderung, bevor der Application Load Balancer die Anforderung an das Ziel sendet. Die möglichen Werte sind append, preserve und remove. Der Standardwert ist append.

  • Wenn der Wert append ist, fügt der Application Load Balancer die Client-IP-Adresse (des letzten Hop) zum X-Forward-For-Header in der HTTP-Anforderung hinzu, bevor sie an Ziele gesendet wird.

  • Wenn der Wert preserve ist, behält Application Load Balancer den X-Forward-For-Header in der HTTP-Anforderung und sendet sie ohne Änderung an Ziele.

  • Wenn der Wert remove ist, entfernt Application Load Balancer den X-Forward-For-Header in der HTTP-Anforderung, bevor sie an Ziele gesendet wird.

routing.http2.enabled

Gibt an, ob HTTP/2 aktiviert ist. Der Standardwert ist true.

waf.fail_open.enabled

Gibt an, ob ein Load Balancer mit AWS WAF aktiviertem Load Balancer Anfragen an Ziele weiterleiten darf, wenn er die Anfrage nicht weiterleiten kann. AWS WAF Die möglichen Werte sind true und false. Der Standardwert ist false.

Anmerkung

Das routing.http.drop_invalid_header_fields.enabled-Attribut wurde eingeführt, um einen Schutz vor HTTP-Desync-Angriffen zu bieten. Das routing.http.desync_mitigation_mode-Attribut wurde hinzugefügt, um Ihren Anwendungen einen umfassenderen Schutz vor HTTP-Desync-Angriffen zu bieten. Sie müssen nicht beide Attribute verwenden und können je nach den Anforderungen Ihrer Anwendung auch nur eines der beiden auswählen.

IP-Adresstyp

Sie können die IP-Adresstypen festlegen, die Clients verwenden können, um auf Ihre Load Balancer, die mit dem Internet verbunden sind, und Ihre internen Load Balancer zuzugreifen.

Im Folgenden sind die IP-Adresstypen aufgeführt:

ipv4

Clients müssen über IPv4-Adressen (z. B. 192.0.2.1) mit dem Load Balancer verbunden werden.

dualstack

Clients können sich mit dem Load Balancer sowohl über IPv4-Adressen (z. B. 192.0.2.1) als auch über IPv6-Adressen (z. B. 2001:0db8:85a3:0:0:8a2e:0370:7334) verbinden.

Überlegungen zum Dualstack-Load-Balancer

  • Der Load Balancer kommuniziert mit Zielen auf der Grundlage des IP-Adresstyps der Zielgruppe.

  • Wenn Sie den Dualstack-Modus für den Load Balancer aktivieren, stellt Elastic Load Balancing einen AAAA-DNS-Eintrag für den Load Balancer bereit. Clients, die mit dem Load Balancer über IPv4-Adressen kommunizieren, lösen den A-DNS-Eintrag auf. Clients, die mit dem Load Balancer über IPv6-Adressen kommunizieren, lösen den AAAA-DNS-Eintrag auf.

  • Der Zugriff auf Ihre internen Dualstack-Load-Balancers über das Internet-Gateway ist blockiert, um einen unbeabsichtigten Internetzugriff zu verhindern. Dies verhindert jedoch nicht den Internetzugang außerhalb von IWG (z. B. über Peering, Transit Gateway AWS Direct Connect, oder). AWS VPN

Load Balancer-Verbindungen

Bei der Verarbeitung einer Anfrage unterhält der Load Balancer zwei Verbindungen: eine Verbindung mit dem Client und eine Verbindung mit einem Ziel. Die Verbindung zwischen dem Load Balancer und dem Client wird auch als Front-End-Verbindung bezeichnet. Die Verbindung zwischen dem Load Balancer und dem Ziel wird auch als Back-End-Verbindung bezeichnet.

Zeitlimit für Verbindungsleerlauf

Das Timeout bei der Verbindungsinaktivität ist der Zeitraum, in dem eine bestehende Client- oder Zielverbindung inaktiv bleiben kann, ohne dass Daten gesendet oder empfangen werden, bevor der Load Balancer die Verbindung schließt.

Um sicherzustellen, dass langwierige Vorgänge wie Datei-Uploads rechtzeitig abgeschlossen werden können, senden Sie vor Ablauf jedes Leerlauf-Timeouts mindestens 1 Byte an Daten und erhöhen Sie die Dauer des Leerlauf-Timeouts nach Bedarf. Wir empfehlen außerdem, das Leerlaufzeitlimit für Ihre Anwendung auf einen höheren Wert als das Leerlaufzeitlimit für den Load Balancer festzulegen. Andernfalls könnte der Load Balancer, wenn die Anwendung die TCP-Verbindung zum Load Balancer nicht ordnungsgemäß schließt, eine Anforderung an die Anwendung senden, bevor er das Paket empfängt, um anzugeben, dass die Verbindung geschlossen ist. Wenn dies der Fall ist, sendet der Load Balancer einen HTTP-502-Bad-Gateway-Fehler an den Client.

Standardmäßig legt Elastic Load Balancing den Leerlauf-Timeout-Wert für Ihren Load Balancer auf 60 Sekunden oder 1 Minute fest. Gehen Sie folgendermaßen vor, um einen anderen Leerlauf-Timeoutwert festzulegen.

Um den Wert für das Leerlauf-Timeout der Verbindung mithilfe der Konsole zu aktualisieren

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich Load Balancers aus.

  3. Wählen Sie den Load Balancer aus.

  4. Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.

  5. Geben Sie unter Verkehrskonfiguration einen Wert für das Timeout bei Verbindungsinaktivität ein. Der gültige Bereich liegt zwischen 1 und 4000 Sekunden.

  6. Wählen Sie Änderungen speichern aus.

Um den Wert für das Leerlauf-Timeout mit dem AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem idle_timeout.timeout_seconds Attribut.

Keepalive-Dauer des HTTP-Clients

Die Keepalive-Dauer des HTTP-Clients ist die maximale Zeitdauer, für die ein Application Load Balancer eine persistente HTTP-Verbindung zu einem Client aufrechterhält. Nach Ablauf der konfigurierten Keepalive-Dauer des HTTP-Clients akzeptiert der Application Load Balancer eine Anfrage und gibt eine Antwort zurück, mit der die Verbindung ordnungsgemäß geschlossen wird.

Die Art der vom Load Balancer gesendeten Antwort hängt von der HTTP-Version ab, die von der Client-Verbindung verwendet wird. Für Clients, die über HTTP 1.x verbunden sind, sendet der Load Balancer einen HTTP-Header, der das Feld enthält. Connection: close Für Clients, die über HTTP/2 verbunden sind, sendet der Load Balancer einen Frame. GOAWAY

Standardmäßig setzen Application Load Balancers den Wert für die Keepalive-Dauer des HTTP-Clients auf 3600 Sekunden oder 1 Stunde. Die Keepalive-Dauer des HTTP-Clients kann nicht ausgeschaltet oder unter den Mindestwert von 60 Sekunden gesetzt werden. Sie können die Keepalive-Dauer des HTTP-Clients jedoch auf maximal 604.800 Sekunden oder 7 Tage erhöhen. Der Application Load Balancer beginnt mit der Dauer der HTTP-Client-Keepalive-Dauer, wenn eine HTTP-Verbindung zu einem Client zum ersten Mal hergestellt wird. Die Dauer läuft weiter, wenn kein Datenverkehr vorhanden ist, und wird erst zurückgesetzt, wenn eine neue Verbindung hergestellt ist.

Der Application Load Balancer weist dem HTTP-Client bei der ersten Verbindung einmal eine Keepalive-Dauer zu. Wenn die Keepalive-Dauer des HTTP-Clients aktualisiert wird, kann dies zu gleichzeitigen Verbindungen mit unterschiedlichen Werten für die Keepalive-Dauer des HTTP-Clients führen. Bei bestehenden Verbindungen wird der Wert für die Keepalive-Dauer des HTTP-Clients beibehalten, der bei der ersten Verbindung angewendet wurde, während alle neuen Verbindungen den aktualisierten Wert für die Keepalive-Dauer des HTTP-Clients erhalten.

Um den Wert für die Keepalive-Dauer des Clients mithilfe der Konsole zu aktualisieren

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich Load Balancers aus.

  3. Wählen Sie den Load Balancer aus.

  4. Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.

  5. Geben Sie unter Verkehrskonfiguration einen Wert für die Keep-Alive-Dauer des HTTP-Clients ein. Der gültige Bereich liegt zwischen 60 und 604800 Sekunden.

  6. Wählen Sie Änderungen speichern aus.

Um den Wert für die Keepalive-Dauer des Clients zu aktualisieren, verwenden Sie AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem client_keep_alive.seconds Attribut.

Zonenübergreifendes Load Balancing

Bei Application Load Balancern ist zonenübergreifendes Load Balancing standardmäßig aktiviert und kann nicht auf Load-Balancer-Ebene geändert werden. Weitere Informationen finden Sie im Abschnitt ZonenübergreifenderLoad Balancing im Benutzerhandbuch für Elastic Load Balancing.

Das Deaktivieren des zonenübergreifenden Load Balancings ist auf Zielgruppenebene möglich. Weitere Informationen finden Sie unter Wenn zonenübergreifendes Load Balancing deaktivieren.

Löschschutz

Um zu verhindern, dass der Load Balancer versehentlich gelöscht wird, können Sie den Löschschutz aktivieren. Standardmäßig ist der Löschschutz für Ihren Load Balancer deaktiviert.

Wenn Sie den Löschschutz für Ihren Load Balancer aktivieren, müssen Sie ihn deaktivieren, bevor Sie den Load Balancer löschen.

So aktivieren Sie mithilfe der Konsole den Löschschutz:

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich Load Balancers aus.

  3. Wählen Sie den Load Balancer aus.

  4. Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.

  5. Aktivieren Sie unter Konfiguration die Option Löschschutz.

  6. Wählen Sie Änderungen speichern aus.

So deaktivieren Sie mithilfe der Konsole den Löschschutz:

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich Load Balancers aus.

  3. Wählen Sie den Load Balancer aus.

  4. Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.

  5. Schalten Sie auf der Seite Konfiguration den Löschschutz aus.

  6. Wählen Sie Änderungen speichern aus.

Um den Löschschutz zu aktivieren oder zu deaktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem deletion_protection.enabled Attribut.

Desynchroner Mitigationsmodus

Der desynchrone Mitigationsmodus schützt Ihre Anwendung vor Problemen aufgrund von HTTP-Desync-Angriffen. Der Load Balancer klassifiziert jede Anforderung anhand ihrer Bedrohungsstufe, lässt sichere Anforderungen zu und mindert dann das Risiko gemäß dem von Ihnen angegebenen Mitigationsmodus. Die desynchronen Mitigationsmodi lauten „Überwachen“, „Defensiv“ und „Am strengsten“. Der Standardmodus ist „Defensiv“, der eine dauerhafte Abwehr gegen HTTP-Desync-Angriffe bietet und gleichzeitig die Verfügbarkeit Ihrer Anwendung gewährleistet. Sie können in den Modus „Am strengsten“ wechseln, um sicherzustellen, dass Ihre Anwendung nur Anforderungen empfängt, die RFC 7230 entsprechen.

Die Bibliothek „http_desync_guardian“ analysiert HTTP-Anforderungen, um HTTP-Desync-Angriffe zu verhindern. Weitere Informationen finden Sie unter HTTP Desync Guardian on. GitHub

Klassifizierungen

Diese Klassifizierungen lauten wie folgt:

  • Konform – Die Anforderung entspricht RFC 7230 und stellt keine bekannten Sicherheitsbedrohungen dar.

  • Akzeptabel – Die Anforderung entspricht nicht RFC 7230, stellt jedoch keine bekannten Sicherheitsbedrohungen dar.

  • Mehrdeutig – Die Anforderung entspricht nicht RFC 7230, stellt jedoch ein Risiko dar, da verschiedene Webserver und Proxys sie unterschiedlich behandeln könnten.

  • Schwerwiegend – Die Anforderung stellt ein hohes Sicherheitsrisiko dar. Der Load Balancer blockiert die Anforderung, sendet dem Client eine 400-Antwort und schließt die Client-Verbindung.

Wenn eine Anforderung nicht RFC 7230 entspricht, erhöht der Load Balancer die DesyncMitigationMode_NonCompliant_Request_Count-Metrik. Weitere Informationen finden Sie unter Application-Load-Balancer-Metriken.

Die Klassifizierung für jede Anforderung ist in den Load-Balancer-Zugriffsprotokollen enthalten. Wenn die Anforderung nicht entspricht, enthalten die Zugriffsprotokolle einen Ursachencode für die Klassifizierung. Weitere Informationen finden Sie unter Gründe für die Klassifizierung.

Modi

In der folgenden Tabelle wird beschrieben, wie Application Load Balancer Anforderungen basierend auf Modus und Klassifizierung behandeln.

Klassifizierung Modus „Überwachen“ Modus „Defensiv“ Modus „Am strengsten“
Konform Zulässig Zulässig Zulässig
Akzeptabel Zulässig Zulässig Blocked
Mehrdeutig Zulässig Zulässig¹ Blocked
Schwerwiegend Zulässig Blocked Blocked

¹ Leitet die Anforderungen weiter, schließt aber die Client- und Zielverbindungen. Es können zusätzliche Gebühren anfallen, wenn Ihr Load Balancer im Modus „Defensiv“ eine große Anzahl von mehrdeutigen Anforderungen empfängt. Dies liegt daran, dass die erhöhte Anzahl neuer Verbindungen pro Sekunde dazu beiträgt, dass die Load-Balancer-Kapazitätseinheiten (LCU) pro Stunde verwendet werden. Sie können die NewConnectionCount-Metrik verwenden, um zu vergleichen, wie Ihr Load Balancer im Modus „Überwachen“ und im Modus „Defensiv“ neue Verbindungen herstellt.

So aktualisieren Sie den desynchronen Mitigationsmodus über die Konsole

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich Load Balancers aus.

  3. Wählen Sie den Load Balancer aus.

  4. Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.

  5. Wählen Sie unter Paketverarbeitung für Desynchroner Mitigationsmodus die Option Defensiv, Am strengsten oder Überwachen aus.

  6. Wählen Sie Änderungen speichern aus.

Um den Desync-Minimierungsmodus zu aktualisieren, verwenden Sie den AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl, wobei das routing.http.desync_mitigation_mode Attribut aufmonitor, defensive oder gesetzt ist. strictest

Beibehalten der Host-Header

Wenn Sie das Attribut Beibehalten des Host-Headers aktivieren, behält Application Load Balancer den Host-Header der HTTP-Anforderung bei und sendet den Header ohne Änderung an Ziele. Wenn der Application Load Balancer mehrere Host-Header empfängt, behält er sie alle bei. Listener-Regeln werden nur auf den ersten empfangenen Host-Header angewendet.

Wenn das Attribut Beibehalten des Host-Headers nicht aktiviert ist, ändert der Application Load Balancer den Host-Header standardmäßig wie folgt:

Wenn „Beibehalten des Host-Headers“ nicht aktiviert ist und der Listener-Port kein Standardport ist: Wenn die Standardports (Port 80 oder 443) nicht verwendet werden, hängen wir die Portnummer an den Host-Header an, sofern sie nicht bereits vom Client hinzugefügt wurde. Zum Beispiel würde der Host-Header in der HTTP-Anforderung mit Host: www.example.com in Host: www.example.com:8080 geändert werden, wenn der Listener-Port ein nicht standardmäßiger Port ist, wie z. B. 8080.

Wenn „Beibehalten des Host-Headers“ nicht aktiviert ist und der Listener-Port ein Standardport ist (Port 80 oder 443): Bei Standard-Listener-Ports (entweder Port 80 oder 443) fügen wir die Portnummer nicht an den ausgehenden Host-Header an. Jede Portnummer, die sich bereits im eingehenden Host-Header befand, wird entfernt.

Die folgende Tabelle zeigt weitere Beispiele dafür, wie Application Load Balancer die Host-Header in der HTTP-Anforderung auf der Grundlage des Listener-Ports behandeln.

Listener-Port Beispielanforderung Host-Header der Anforderung „Beibehaltung des Host-Headers“ ist deaktiviert (Standardverhalten) „Beibehaltung des Host-Headers“ ist aktiviert
Die Anforderung wird über den standardmäßigen HTTP/HTTPS-Listener gesendet. GET /index.html HTTP/1.1 Host: example.com example.com example.com example.com
Die Anfrage wird über den Standard-HTTP-Listener gesendet und der Host-Header hat einen Port (z. B. 80 oder 443). GET /index.html HTTP/1.1 Host: example.com:80 example.com:80 example.com example.com:80
Die Anforderung hat einen absoluten Pfad. GET https://dns_name/index.html HTTP/1.1 Host: example.com example.com dns_name example.com
Die Anfrage wird über einen nicht standardmäßigen Listener-Port gesendet (z. B. 8080) GET /index.html HTTP/1.1 Host: example.com example.com example.com:8080 example.com
Die Anforderung wird über einen nicht standardmäßigen Listener-Port gesendet und der Host-Header enthält einen Port (z. B. 8080). GET /index.html HTTP/1.1 Host: example.com:8080 example.com:8080 example.com:8080 example.com:8080
So aktivieren Sie die Beibehaltung des Host-Headers

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Klicken Sie im Navigationsbereich auf Load Balancers.

  3. Wählen Sie den Load Balancer aus.

  4. Klicken Sie auf der Registerkarte Attribute auf Bearbeiten.

  5. Aktivieren Sie unter Paketverarbeitung die Option Beibehaltung des Host-Headers.

  6. Wählen Sie Änderungen speichern aus.

Um die Aufbewahrung von Host-Headern zu aktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl, bei dem das routing.http.preserve_host_header.enabled Attribut auf gesetzt isttrue.

Application Load Balancer und AWS WAF

Sie können es AWS WAF zusammen mit Ihrem Application Load Balancer verwenden, um Anfragen auf der Grundlage der Regeln in einer Web-Zugriffskontrollliste (Web-ACL) zuzulassen oder zu blockieren. Weitere Informationen finden Sie unter Arbeiten mit Web-ACLs im AWS WAF -Entwicklerhandbuch.

Wenn der Load Balancer keine Antwort von erhalten kann AWS WAF, gibt er standardmäßig einen HTTP 500-Fehler zurück und leitet die Anfrage nicht weiter. Wenn Sie möchten, dass Ihr Load Balancer Anfragen an Ziele weiterleitet, auch wenn er keinen Kontakt herstellen kann AWS WAF, können Sie die Integration aktivieren AWS WAF . Um zu überprüfen, ob Ihr Load Balancer integriert ist AWS WAF, wählen Sie Ihren Load Balancer auf der AWS Management Console Registerkarte Integrierte Dienste aus.

Vordefinierte Web-ACLs

Wenn Sie die AWS WAF Integration aktivieren, können Sie wählen, ob automatisch eine neue Web-ACL mit vordefinierten Regeln erstellt werden soll. Die vordefinierte Web-ACL umfasst drei AWS verwaltete Regeln, die Schutz vor den häufigsten Sicherheitsbedrohungen bieten.

  • AWSManagedRulesAmazonIpReputationList‐ Die Regelgruppe der Amazon IP-Reputationsliste blockiert IP-Adressen, die typischerweise mit Bots oder anderen Bedrohungen in Verbindung stehen. Weitere Informationen finden Sie unter verwaltete Regelgruppe der Amazon IP-Reputationsliste im AWS WAF Entwicklerhandbuch.

  • AWSManagedRulesCommonRuleSet‐ Die Regelgruppe Core Rule Set (CRS) bietet Schutz vor der Ausnutzung einer Vielzahl von Sicherheitslücken, darunter einige der risikoreichen und häufig auftretenden Sicherheitslücken, die in OWASP-Publikationen wie OWASP Top 10 beschrieben werden. Weitere Informationen finden Sie unter verwaltete Regelgruppe Core Rule Set (CRS) im Entwicklerhandbuch.AWS WAF

  • AWSManagedRulesKnownBadInputsRuleSet‐ Die Regelgruppe Bekannte fehlerhafte Eingaben blockiert Anforderungsmuster, die bekanntermaßen ungültig sind und mit der Ausnutzung oder Entdeckung von Sicherheitslücken in Verbindung stehen. Weitere Informationen finden Sie unter Verwaltete Regelgruppe „Bekannte fehlerhafte Eingaben“ im AWS WAF Entwicklerhandbuch.

Um die AWS WAF Verwendung der Konsole zu aktivieren

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich Load Balancers aus.

  3. Wählen Sie den Load Balancer aus.

  4. Erweitern Sie auf der Registerkarte Integrationen die Option AWS Web Application Firewall (WAF) und wählen Sie Einer WAF-Web-ACL zuordnen aus.

  5. Wählen Sie unter Web-ACL die Option Vordefinierte Web-ACL automatisch erstellen oder wählen Sie eine vorhandene Web-ACL aus.

  6. Wählen Sie unter Regelaktion die Option Blockieren oder Zählen aus.

  7. Wählen Sie Bestätigen aus.

Um AWS WAF Fail Open zu aktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl, bei dem das waf.fail_open.enabled Attribut auf gesetzt isttrue.