Attribute für Ihren Application Load Balancer bearbeiten

Nachdem Sie einen Application Load Balancer erstellt haben, können Sie seine Attribute bearbeiten.

Zeitlimit für Verbindungsleerlauf

Das Timeout bei der Verbindungsinaktivität ist der Zeitraum, für den 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.

Application Load Balancer unterstützen keine HTTP/2-PING-Frames. Diese setzen das Timeout der Verbindung im Leerlauf nicht zurück.

Elastic Load Balancing setzt den Timeoutwert für die Leerlaufzeit für Ihren Load Balancer standardmäßig auf 60 Sekunden.

Console

Um den Wert für den Timeout bei Verbindungsinaktivität zu aktualisieren

1. Öffnen Sie die EC2 Amazon-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.

AWS CLI

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

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem idle_timeout.timeout_seconds Attribut. Der gültige Bereich liegt zwischen 1 und 4000 Sekunden.

aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn load-balancer-arn \
    --attributes "Key=idle_timeout.timeout_seconds,Value=120"

CloudFormation

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

Aktualisieren Sie die AWS::ElasticLoadBalancingV2::LoadBalancerRessource so, dass sie das idle_timeout.timeout_seconds Attribut enthält. Der gültige Bereich liegt zwischen 1 und 4000 Sekunden.

Resources:
  myLoadBalancer:
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
    Properties:
      Name: my-alb
      Type: application
      Scheme: internal
      Subnets: 
        - !Ref subnet-AZ1
        - !Ref subnet-AZ2
      SecurityGroups: 
        - !Ref mySecurityGroup
      LoadBalancerAttributes: 
        - Key: "idle_timeout.timeout_seconds"
          Value: "120"

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 unterhält. Nach Ablauf der konfigurierten Keepalive-Dauer des HTTP-Clients akzeptiert der Application Load Balancer eine weitere Anfrage und gibt dann 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 legt Application Load Balancer den Wert für die Keepalive-Dauer des HTTP-Clients für Load Balancer auf 3600 Sekunden oder 1 Stunde fest. Die Keepalive-Dauer des HTTP-Clients kann nicht ausgeschaltet oder unter die Mindestdauer 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. Ein 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 wird fortgesetzt, wenn kein Datenverkehr vorhanden ist, und wird erst zurückgesetzt, wenn eine neue Verbindung hergestellt ist.

Wenn der Load Balancer-Verkehr mithilfe von Zonal Shift oder Zonal Autoshift von einer beeinträchtigten Availability Zone weg verlagert wird, stellen Clients mit bestehenden offenen Verbindungen möglicherweise weiterhin Anfragen an den beeinträchtigten Standort, bis die Clients wieder eine Verbindung herstellen. Um eine schnellere Wiederherstellung zu unterstützen, sollten Sie einen niedrigeren Wert für die Keepalive-Dauer festlegen, um die Dauer zu begrenzen, für die Clients mit einem Load Balancer verbunden bleiben. Weitere Informationen finden Sie unter Beschränken der Zeit, in der Clients mit Ihren Endpunkten verbunden bleiben, im Amazon Application Recovery Controller (ARC) Developer Guide.

Anmerkung

Wenn der Load Balancer den IP-Adresstyp Ihres Application Load Balancer auf umstelltdualstack-without-public-ipv4, wartet der Load Balancer, bis alle aktiven Verbindungen abgeschlossen sind. Um den Zeitaufwand für den Wechsel des IP-Adresstyps für Ihren Application Load Balancer zu verringern, sollten Sie die Dauer der HTTP-Client-Keepalive-Dauer verringern.

Der Application Load Balancer weist dem HTTP-Client bei der ersten Verbindung einen Wert für die Keepalive-Dauer zu. Wenn Sie die Keepalive-Dauer des HTTP-Clients aktualisieren, 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. Neue Verbindungen erhalten den aktualisierten Wert für die Keepalive-Dauer des HTTP-Clients.

Console

Um die Keepalive-Dauer des Clients zu aktualisieren

1. Öffnen Sie die EC2 Amazon-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 Keepalive-Dauer des HTTP-Clients ein. Der gültige Bereich liegt zwischen 60 und 604800 Sekunden.

6. Wählen Sie Änderungen speichern aus.

AWS CLI

Um die Keepalive-Dauer des Clients zu aktualisieren

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem client_keep_alive.seconds Attribut. Der gültige Bereich liegt zwischen 60 und 604800 Sekunden.

aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn load-balancer-arn \
    --attributes "Key=client_keep_alive.seconds,Value=7200"

CloudFormation

Um die Keepalive-Dauer des Clients zu aktualisieren

Aktualisieren Sie die AWS::ElasticLoadBalancingV2::LoadBalancerRessource so, dass sie das client_keep_alive.seconds Attribut enthält. Der gültige Bereich liegt zwischen 60 und 604800 Sekunden.

Resources:
  myLoadBalancer:
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
    Properties:
      Name: my-alb
      Type: application
      Scheme: internal
      Subnets: 
        - !Ref subnet-AZ1
        - !Ref subnet-AZ2
      SecurityGroups: 
        - !Ref mySecurityGroup
      LoadBalancerAttributes: 
        - Key: "client_keep_alive.seconds"
          Value: "7200"

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.

Console

Um den Löschschutz zu aktivieren oder zu deaktivieren

1. Öffnen Sie die EC2 Amazon-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 oder deaktivieren Sie unter Schutz den Löschschutz.

6. Wählen Sie Änderungen speichern aus.

AWS CLI

Um den Löschschutz zu aktivieren oder zu deaktivieren

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

aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn load-balancer-arn \
    --attributes "Key=deletion_protection.enabled,Value=true"

CloudFormation

Um den Löschschutz zu aktivieren oder zu deaktivieren

Aktualisieren Sie die AWS::ElasticLoadBalancingV2::LoadBalancerRessource so, dass sie das deletion_protection.enabled Attribut enthält.

Resources:
  myLoadBalancer:
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
    Properties:
      Name: my-alb
      Type: application
      Scheme: internal
      Subnets: 
        - !Ref subnet-AZ1
        - !Ref subnet-AZ2
      SecurityGroups: 
        - !Ref mySecurityGroup
      LoadBalancerAttributes: 
        - Key: "deletion_protection.enabled"
          Value: "true"

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.

Console

Um den Desync-Minimierungsmodus zu aktualisieren

1. Öffnen Sie die EC2 Amazon-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 Verkehrskonfiguration, Paketverarbeitung für den Desync-Minderungsmodus die Optionen Defensive, Strictest oder Monitor aus.

6. Wählen Sie Änderungen speichern aus.

AWS CLI

Um den Desync-Minimationsmodus zu aktualisieren

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem Attribut. routing.http.desync_mitigation_mode Die möglichen Werte sind monitor, defensive oder strictest. Der Standardwert ist defensive.

aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn load-balancer-arn \
    --attributes "Key=routing.http.desync_mitigation_mode,Value=monitor"

CloudFormation

Um den Desync-Minimationsmodus zu aktualisieren

Aktualisieren Sie die AWS::ElasticLoadBalancingV2::LoadBalancerRessource so, dass sie das Attribut enthält. routing.http.desync_mitigation_mode Die möglichen Werte sind monitor, defensive oder strictest. Der Standardwert ist defensive.

Resources:
  myLoadBalancer:
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
    Properties:
      Name: my-alb
      Type: application
      Scheme: internal
      Subnets: 
        - !Ref subnet-AZ1
        - !Ref subnet-AZ2
      SecurityGroups: 
        - !Ref mySecurityGroup
      LoadBalancerAttributes: 
        - Key: "routing.http.desync_mitigation_mode"
          Value: "monitor"

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 Anfrage wird auf dem HTTP/HTTPS Standard-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

Console

So aktivieren Sie die Beibehaltung des Host-Headers

1. Öffnen Sie die EC2 Amazon-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.

AWS CLI

So aktivieren Sie die Beibehaltung des Host-Headers

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

aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn load-balancer-arn \
    --attributes "Key=routing.http.preserve_host_header.enabled,Value=true"

CloudFormation

So aktivieren Sie die Beibehaltung des Host-Headers

Aktualisieren Sie die AWS::ElasticLoadBalancingV2::LoadBalancerRessource, sodass sie das routing.http.preserve_host_header.enabled Attribut enthält.

Resources:
  myLoadBalancer:
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
    Properties:
      Name: my-alb
      Type: application
      Scheme: internal
      Subnets: 
        - !Ref subnet-AZ1
        - !Ref subnet-AZ2
      SecurityGroups: 
        - !Ref mySecurityGroup
      LoadBalancerAttributes: 
        - Key: "routing.http.preserve_host_header.enabled"
          Value: "true"