So funktioniert Elastic Load Balancing - Elastic Load Balancing
Availability Zones und Load-Balancer-KnotenWeiterleitung von AnforderungenLoad-Balancer-SchemaIP-AdresstypenNetzwerk-MTU

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.

So funktioniert Elastic Load Balancing

Ein Load Balancer akzeptiert eingehenden Datenverkehr von Clients und leitet Anfragen an seine registrierten Ziele (z. B. EC2 Instances) in einer oder mehreren Availability Zones weiter. Der Load Balancer überwacht auch den Zustand seiner registrierten Ziele und stellt sicher, dass er den Datenverkehr nur an ordnungsgemäß funktionierende Ziele weiterleitet. Wenn der Load Balancer ein fehlerhaftes Ziel erkennt, stoppt er das Weiterleiten von Datenverkehr an dieses Ziel. Anschließend wird die Weiterleitung von Datenverkehr an dieses Ziel fortgesetzt, wenn er erkennt, dass das Ziel wieder fehlerfrei ist.

Sie konfigurieren Ihren Load Balancer für eingehenden Datenverkehr, indem Sie einen oder mehrere Listener angeben. Ein Listener ist ein Prozess, der Verbindungsanfragen überprüft. Es wird mit einem Protokoll und einer Portnummer für Verbindungen von Clients zum Load Balancer konfiguriert. Ebenso ist es mit einem Protokoll und einer Portnummer für Verbindungen vom Load Balancer zu den Zielen konfiguriert.

Availability Zones und Load-Balancer-Knoten

Wenn Sie eine Availability Zone für Ihren Load Balancer aktivieren, erstellt Elastic Load Balancing einen Load-Balancer-Knoten in der Availability Zone. Wenn Sie Ziele in einer Availability Zone registrieren, aber die Availability Zone nicht aktivieren, erhalten diese registrierten Ziele keinen Datenverkehr. Ihr Load Balancer ist am effektivsten, wenn Sie dafür sorgen, dass jede aktivierte Availability Zone mindestens ein registriertes Ziel hat.

Wir empfehlen, mehrere Availability Zones für alle Load Balancer zu aktivieren. Bei einem Application Load Balancer ist es jedoch erforderlich, dass Sie mindestens zwei Availability Zones aktivieren. Diese Konfiguration stellt sicher, dass der Load Balancer weiterhin Datenverkehr weiterleiten kann. Der Load Balancer kann den Datenverkehr an fehlerfreie Ziele in einer anderen Availability Zone weiterleiten, falls eine Availability Zone ausfällt oder keine fehlerfreien Ziele mehr hat.

Nachdem Sie eine Availability Zone deaktiviert haben, bleiben die Ziele in dieser Availability Zone für den Load Balancer registriert. Auch wenn sie registriert bleiben, leitet der Load Balancer keinen Datenverkehr an sie weiter.

Zonenübergreifendes Load Balancing

Die Knoten für Ihren Load Balancer verteilen Anforderungen von Clients auf registrierte Ziele. Wenn zonenübergreifendes Load Balancing aktiviert ist, verteilt jeder Load Balancer-Knoten den Datenverkehr gleichmäßig auf die registrierten Ziele in allen aktivierten Availability Zones. Wenn zonenübergreifendes Load Balancing deaktiviert ist, verteilt jeder Load Balancer-Knoten den Datenverkehr gleichmäßig nur auf die registrierten Ziele in seiner Availability Zone.

Die folgenden Diagramme veranschaulichen die Auswirkungen des zonenübergreifenden Load Balancings mit Round Robin als Standard-Routing-Algorithmus. Es gibt zwei aktivierte Availability Zones mit zwei Zielen in Availability Zone A und acht Zielen in Availability Zone B. Clients senden Anfragen und Amazon Route 53 beantwortet jede Anfrage mit der IP-Adresse eines der Load-Balancer-Knoten. Basierend auf dem Round-Robin-Routing-Algorithmus wird der Datenverkehr so verteilt, dass jeder Load-Balancer-Knoten 50 % des Datenverkehrs von den Clients erhält. Jeder Load Balancer-Knoten verteilt seinen Anteil des Datenverkehrs auf die registrierten Ziele in seinem Anwendungsbereich.

Wenn zonenübergreifendes Load Balancing aktiviert ist, erhält jedes der 10 Ziele 10 % des Datenverkehrs. Der Grund hierfür ist, dass jeder Load Balancer-Knoten seine 50 % des Client-Datenverkehrs an alle 10 Ziele weiterleiten kann.

Wenn zonenübergreifendes Load Balancing aktiviert ist

Wenn zonenübergreifendes Load Balancing deaktiviert ist:

  • Jedes der beiden Ziele in Availability Zone A erhält 25 % des Datenverkehrs.

  • Jedes der acht Ziele in Availability Zone B erhält 6,25 % des Datenverkehrs.

Der Grund hierfür ist, dass jeder Load Balancer-Knoten seine 50 % des Client-Datenverkehrs nur an Ziele in seiner Availability Zone weiterleiten kann.

Wenn zonenübergreifendes Load Balancing deaktiviert ist

Bei Application Load Balancern ist zonenübergreifendes Load Balancing immer auf Load-Balancer-Ebene aktiviert. Auf Zielgruppenebene kann zonenübergreifendes Load Balancing deaktiviert werden. Weitere Informationen finden Sie unter Deaktivieren von zonenübergreifendem Load Balancing im Benutzerhandbuch für Application Load Balancer.

Bei Network Load Balancern und Gateway Load Balancern ist zonenübergreifendes Load Balancing standardmäßig deaktiviert. Nachdem Sie einen Load Balancer erstellt haben, können Sie zonenübergreifendes Load Balancing jederzeit aktivieren oder deaktivieren. Weitere Informationen finden Sie unter Zonenübergreifendes Load Balancing im Benutzerhandbuch für Network Load Balancers.

Wenn Sie einen Classic Load Balancer erstellen, hängt die Voreinstellung für zonenübergreifendes Load Balancing davon ab, wie Sie den Load Balancer erstellen. Mit der API oder CLI wird das zonenübergreifende Load Balancing standardmäßig deaktiviert. Bei der ist die AWS Management Console Option zur Aktivierung des zonenübergreifenden Lastenausgleichs standardmäßig ausgewählt. Nachdem Sie einen Classic Load Balancer erstellt haben, können Sie zonenübergreifendes Load Balancing jederzeit aktivieren oder deaktivieren. Weitere Informationen finden Sie unter Aktivieren von zonenübergreifendem Load Balancing im Benutzerhandbuch für Classic Load Balancer.

Zonenverschiebung

Zonal Shift ist eine Funktion in Amazon Application Recovery Controller (ARC) (ARC). Mit der Zonenverschiebung können Sie eine Load-Balancer-Ressource mit einer einzigen Aktion aus einer beeinträchtigten Availability Zone verlagern. Auf diese Weise können Sie den Betrieb von anderen fehlerfreien Availability Zones in einer AWS-Region fortsetzen.

Wenn Sie eine Zonenverschiebung starten, sendet Ihr Load Balancer den Datenverkehr für die Ressource nicht mehr an die betroffene Availability Zone. ARC erzeugt die Zonenverschiebung sofort. Es kann jedoch eine kurze Zeit dauern, in der Regel bis zu einigen Minuten, bis bestehende Verbindungen in der betroffenen Availability Zone hergestellt sind. Weitere Informationen finden Sie unter So funktioniert eine zonale Schicht: Zustandsprüfungen und zonale IP-Adressen im Amazon Application Recovery Controller (ARC) Developer Guide.

Bevor Sie die Zonenverschiebung verwenden, sollten Sie Folgendes beachten:

  • Zonal Shift wird unterstützt, wenn Sie einen Network Load Balancer mit aktiviertem oder deaktiviertem zonenübergreifendem Load Balancing verwenden.

  • Die Zonenverschiebung wird nicht unterstützt, wenn Sie einen Application Load Balancer als Accelerator-Endpunkt in AWS Global Accelerator verwenden.

  • Sie können eine Zonenverschiebung für einen bestimmten Load Balancer nur für eine Availability Zone starten. Eine Zonenverschiebung lässt sich nicht für mehrere Availability Zones starten.

  • AWS entfernt proaktiv IP-Adressen des zonalen Load Balancers aus DNS, wenn sich mehrere Infrastrukturprobleme auf Dienste auswirken. Prüfen Sie immer die aktuelle Kapazität der Availability Zone, bevor Sie mit einer Zonenverschiebung beginnen. Wenn bei Ihren Load Balancern das zonenübergreifende Load Balancing deaktiviert ist und Sie eine Zonenverschiebung verwenden, um eine zonale Load-Balancer-IP-Adresse zu entfernen, verliert die Availability Zone, die von der Zonenverschiebung betroffen ist, auch die Zielkapazität.

  • Wenn ein Application Load Balancer das Ziel eines Network Load Balancers ist, starten Sie die Zonenverschiebung immer vom Network Load Balancer aus. Wenn Sie eine Zonenverschiebung vom Application Load Balancer aus starten, erkennt der Network Load Balancer die Verschiebung nicht und sendet weiterhin Datenverkehr an den Application Load Balancer.

Weitere Anleitungen und Informationen finden Sie unter Bewährte Methoden für Zonenverschiebungen in ARC im Amazon Application Recovery Controller (ARC) Developer Guide.

Weiterleitung von Anforderungen

Bevor ein Client eine Anforderung an Ihren Load Balancer sendet, löst der Load Balancer den Domainnamen mithilfe eines Domain Name System- (DNS)-Server auf. Der DNS-Eintrag wird von Amazon gesteuert, da sich Ihre Load Balancer in der amazonaws.com-Domain befinden. Die Amazon DNS-Server geben mindestens eine IP-Adresse an den Client zurück. Dies sind die IP-Adressen der Load Balancer-Knoten für Ihren Load Balancer. Mit Network Load Balancern erstellt Elastic Load Balancing eine Netzwerkschnittstelle für jede Availability Zone, die Sie aktivieren, und verwendet diese, um eine statische IP-Adresse zu erhalten. Sie können optional eine Elastic-IP-Adresse mit jeder Netzwerkschnittstelle verknüpfen, wenn Sie den Network Load Balancer erstellen.

Da der Datenverkehr für Ihre Anwendung sich im Laufe der Zeit ändert, skaliert Elastic Load Balancing Ihren Load Balancer und aktualisiert den DNS-Eintrag. Der DNS-Eintrag gibt auch die time-to-live (TTL) von 60 Sekunden an. Dadurch wird sichergestellt, dass die IP-Adressen aufgrund des sich ändernden Datenverkehrs schnell neu zugeordnet werden können.

Der Client bestimmt, welche IP-Adresse zum Senden von Anforderungen an den Load Balancer verwendet werden. Der Load Balancer-Knoten, der die Anforderung empfängt, wählt ein fehlerfreies registriertes Ziel aus und sendet die Anforderung über die private IP-Adresse an das Ziel.

Weitere Informationen finden Sie unter Weiterleiten von Datenverkehr an einen ELB Load Balancer im Entwicklerhandbuch von Amazon Route 53.

Weiterleitungsalgorithmus

Bei Application Load Balancern verwendet der Load-Balancer-Knoten, der die Anfrage empfängt, den folgenden Prozess:

  1. Wertet die Listener-Regeln in der Reihenfolge ihrer Priorität aus, um zu bestimmen, welche Regel angewendet werden soll.

  2. Wählt ein Ziel aus der Zielgruppe für die Regelaktion aus, wobei der für die Zielgruppe konfigurierte Routingalgorithmus verwendet wird. Der Standard-Routingalgorithmus ist Round Robin. Die Weiterleitung erfolgt unabhängig für jede Zielgruppe, auch wenn ein Ziel bei mehreren Zielgruppen registriert ist.

Bei Network Load Balancern verwendet der Load-Balancer-Knoten, der die Verbindung empfängt, den folgenden Prozess:

  1. Wählt ein Ziel aus der Zielgruppe für die Standardregel mit einem Flow-Hash-Algorithmus aus. Basiert den Algorithmus auf:

    • Protokoll

    • Quell-IP-Adresse und Quellport

    • Ziel-IP-Adresse und Zielport

    • TCP-Sequenznummer

  2. Leitet jede einzelne TCP-Verbindung für die Dauer der Verbindung an ein einzelnes Ziel weiter. Die TCP-Verbindungen von einem Client verfügen über unterschiedliche Quell-Ports und Sequenznummern und können an verschiedene Ziele geleitet werden.

Bei Classic Load Balancern wählt der Load-Balancer-Knoten, der die Anfrage empfängt, wie folgt eine registrierte Instance aus:

  • Verwendet den Roundrobin-Weiterleitungsalgorithmus für TCP-Listener

  • Routingalgorithmus für HTTP- und HTTPS-Listener mit den wenigsten ausstehenden Anforderungen

HTTP-Verbindungen

Classic Load Balancer verwenden vorab geöffnete Verbindungen, Application Load Balancer jedoch nicht. Sowohl Classic Load Balancer als auch Application Load Balancer verwenden Verbindungsmultiplexing. Das bedeutet, dass Anfragen von mehreren Clients auf mehreren Front-End-Verbindungen über eine einzige Back-End-Verbindung an ein bestimmtes Ziel weitergeleitet werden können. Das Verbindungsmultiplexing verbessert die Latenz und reduziert die Last für Ihre Anwendungen. Um das Verbindungsmultiplexing zu verhindern, deaktivieren Sie HTTP-keep-alive-Header, indem Sie den Connection: close-Header in Ihren HTTP-Antworten festlegen.

Application Load Balancer und Classic Load Balancer unterstützen HTTP über Pipelines auf Frontend-Verbindungen. Es werden jedoch keine HTTP-Pipelines für Backend-Verbindungen unterstützt.

Application Load Balancer unterstützen die folgenden HTTP-Anforderungsmethoden: GET, HEAD, POST, PUT, DELETE, OPTIONS und PATCH.

Application Load Balancer unterstützen die folgenden Protokolle in Frontend-Verbindungen: HTTP/0.9, HTTP/1.0, HTTP/1.1 und HTTP/2. Sie können HTTP/2 nur mit HTTPS-Listenern verwenden und bis zu 128 Anfragen parallel mit einer HTTP/2-Verbindung senden. Application Load Balancers unterstützen auch Verbindungs-Upgrades von HTTP auf. WebSockets Wenn es jedoch ein Verbindungs-Upgrade gibt, gelten die Routing-Regeln und AWS WAF Integrationen für den Application Load Balancer Listener nicht mehr.

Application Load Balancer verwenden standardmäßig HTTP/1.1 für Backend-Verbindungen (Load Balancer zum registrierten Ziel). Sie können jedoch die Protokollversion verwenden, um die Anfrage mit HTTP/2 oder gRPC an die Ziele zu senden. Weitere Informationen finden Sie unter Protokollversionen. Der keep-alive-Header wird bei Backend-Verbindungen standardmäßig unterstützt. Für HTTP/1.0 Anforderungen von Clients, die keinen Host-Header haben, generiert der Load Balancer einen Host-Header für die HTTP/1.1-Anforderungen, die über die Backend-Verbindungen gesendet werden. Der Host-Header enthält den DNS-Namen des Load Balancers.

Classic Load Balancer unterstützen die folgenden Protokolle in Frontend-Verbindungen (Client zu Load Balancer): HTTP/0.9, HTTP/1.0 und HTTP/1.1. Sie verwenden HTTP/1.1 für Backend-Verbindungen (Load Balancer zu registriertem Ziel). Der keep-alive-Header wird bei Backend-Verbindungen standardmäßig unterstützt. Für HTTP/1.0 Anforderungen von Clients, die keinen Host-Header haben, generiert der Load Balancer einen Host-Header für die HTTP/1.1-Anforderungen, die über die Backend-Verbindungen gesendet werden. Der Host-Header enthält die IP-Adresse des Load-Balancer-Knotens.

HTTP-Header

Application Load Balancer und Classic Load Balancer fügen automatisch die Header X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Port zur Anfrage hinzu.

Application Load Balancer konvertieren die Hostnamen in HTTP-Host-Headern in Kleinbuchstaben, bevor sie an Ziele gesendet werden.

Für Frontend-Verbindungen mit HTTP/2 sind die Header-Namen in Kleinbuchstaben angegeben. Bevor die Anfrage per HTTP/1.1 an das Ziel gesendet wird, werden die folgenden Header-Namen in Groß- und Kleinschreibung konvertiert: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, Host, X-Amzn-Trace-ID, Upgrade und Connection. Alle anderen Header-Namen sind in Kleinbuchstaben.

Application Load Balancer und Classic Load Balancer berücksichtigen den Verbindungs-Header aus der eingehenden Client-Anfrage, nachdem die Antwort über Proxy an den Client zurückgegeben wurde.

Wenn Application Load Balancer und Classic Load Balancer, die HTTP/1.1 verwenden, einen Expect: 100-Continue-Header erhalten, antworten sie sofort mit HTTP/1.1 100 Continue, ohne den Content-Length-Header zu prüfen. Der Header der Expect: 100-Continue-Anfrage wird nicht an die Ziele weitergeleitet.

Bei Verwendung von HTTP/2 unterstützen Application Load Balancer den Expect: 100-Continue-Header von Client-Anfragen nicht. Der Application Load Balancer wird nicht mit HTTP/2 100 Continue antworten oder diesen Header an die Ziele weiterleiten.

HTTP-Header-Limits

Die folgenden Größenbeschränkungen für Application Load Balancer sind harte Grenzwerte, die nicht geändert werden können.

  • Anforderungszeile: 16 K

  • Einzelner Header: 16 K

  • Gesamter Antwort-Header: 32 K

  • Gesamter Anfrage-Header: 64 K

Load-Balancer-Schema

Wenn Sie einen Load Balancer erstellen, müssen Sie entscheiden, ob es ein interner Load Balancer oder ein mit dem Internet verbundener Load Balancer werden soll.

Die Knoten eines mit dem Internet verbundenen Load Balancers haben öffentliche IP-Adressen. Der DNS-Name eines mit dem Internet verbundenen Load Balancers ist öffentlich zu den öffentlichen IP-Adressen der Knoten auflösbar. Daher können mit dem Internet verbundene Load Balancer Anfragen von Clients über das Internet weiterleiten.

Die Knoten eines internen Load Balancers haben nur private IP-Adressen. Der DNS-Name eines internen Load Balancers ist öffentlich zu den privaten IP-Adressen der Knoten auflösbar. Daher kann der interne Load Balancer nur Anforderungen von Clients mit Zugriff auf die VPC für den Load Balancer weiterleiten.

Sowohl mit dem Internet verbundene als auch interne Load Balancer leiten Anfragen an Ihre Ziele unter Verwendung privater IP-Adressen weiter. Daher benötigen Ihre Ziele keine öffentlichen IP-Adressen für den Empfang von Anfragen von einem internen oder einem mit dem Internet verbundenen Load Balancer.

Wenn Ihre Anwendung über mehrere Ebenen verfügt, können Sie eine Architektur entwerfen, die sowohl interne als auch internetbasierte Load Balancer verwendet. Dies gilt beispielsweise, wenn Ihre Anwendung Webserver verwendet, die mit dem Internet verbunden sein müssen, und Anwendungsserver, die nur mit den Webservern verbunden sind. Erstellen Sie einen mit dem Internet verbundenen Load Balancer und registrieren Sie die Webserver bei ihm. Erstellen Sie einen internen Load Balancer und registrieren Sie die Anwendungsserver bei ihm. Die Webserver empfangen Anforderungen von dem mit dem Internet verbundenen Load Balancer und senden die Anforderungen für die Anwendungsserver an den internen Load Balancer. Die Anwendungsserver empfangen Anforderungen vom internen Load Balancer.

IP-Adresstypen

Der IP-Adresstyp, den Sie für Ihren Load Balancer angeben, bestimmt, wie Clients mit dem Load Balancer kommunizieren können.

  • IPv4 nur — Clients kommunizieren über öffentliche und private IPv4 Adressen. Die Subnetze, die Sie für Ihren Load Balancer auswählen, müssen IPv4 Adressbereiche haben.

  • Dualstack — Clients kommunizieren über öffentliche und private Adressen. IPv4 IPv6 Die Subnetze, die Sie für Ihren Load Balancer auswählen, müssen Adressbereiche haben IPv4 . IPv6

  • Dualstack ohne öffentlich IPv4 — Clients kommunizieren über öffentliche und private IPv6 Adressen sowie private Adressen. IPv4 Die Subnetze, die Sie für Ihren Load Balancer auswählen, müssen Adressbereiche haben IPv4 . IPv6 Diese Option wird vom internal Load Balancer-Schema nicht unterstützt.

In der folgenden Tabelle werden die IP-Adresstypen beschrieben, die für jeden Load Balancer-Typ unterstützt werden.

Load balancer type (Load Balancer-Typ) IPv4 nur Dual-Stack Dualstack ohne Öffentlichkeit IPv4
Application Load Balancer Ja Ja Ja
Network Load Balancer Ja Ja Nein
Gateway Load Balancer Ja Ja Nein
Classic Load Balancer Ja Nein Nein

Der IP-Adresstyp, den Sie für Ihre Zielgruppe angeben, bestimmt, wie der Load Balancer mit Zielen kommunizieren kann.

  • IPv4 nur — Der Load Balancer kommuniziert über private Adressen. IPv4 Sie müssen Ziele mit IPv4 Adressen mit einer IPv4 Zielgruppe registrieren.

  • IPv6 nur — Der Load Balancer kommuniziert über IPv6 Adressen. Sie müssen Ziele mit IPv6 Adressen mit einer IPv6 Zielgruppe registrieren. Die Zielgruppe muss mit einem Dual-Stack-Loadbalancer verwendet werden.

In der folgenden Tabelle werden die IP-Adresstypen beschrieben, die für jedes Zielgruppenprotokoll unterstützt werden.

Protokoll der Zielgruppe IPv4 nur IPv6 nur
HTTP und HTTPS Ja Ja
TCP Ja Ja
TLS Ja Ja
UDP und TCP_UDP Ja Ja
GENF - -

Netzwerk-MTU für Ihren Load Balancer

Die maximale Übertragungseinheit (MTU) bestimmt die Größe des größten Pakets, das über das Netzwerk gesendet werden kann, in Bytes. Je größer die MTU einer Verbindung, desto mehr Daten können in einem einzelnen Paket übergeben werden. Ethernet-Rahmen bestehen aus dem Paket, also den eigentlichen Daten, die Sie senden, sowie aus den dazugehörigen Netzwerk-Overhead-Informationen. Über ein Internet-Gateway gesendeter Datenverkehr hat eine MTU von 1500. Das bedeutet, dass ein Paket mit mehr als 1500 Bytes fragmentiert und in mehreren Frames versendet wird. Wenn im IP-Header Don't Fragment festgelegt ist, wird das Paket gelöscht.

Die MTU-Größe auf Load-Balancer-Knoten ist nicht konfigurierbar. Jumbo-Frames (9001 MTU) sind Standard bei Load-Balancer-Knoten für Application Load Balancer, Network Load Balancer und Classic Load Balancer. Gateway Load Balancer unterstützen 8500 MTU. Weitere Informationen finden Sie unter Maximum Transmission Unit (MTU) im Benutzerhandbuch für Gateway Load Balancer.

Die Pfad-MTU ist die maximale Paketgröße, die auf dem Pfad zwischen dem sendenden Host und dem empfangenden Host unterstützt wird. Path MTU Discovery (PMTUD) wird verwendet, um den Pfad-MTU-Wert zwischen zwei Geräten zu ermitteln. Path MTU Discovery ist besonders wichtig, wenn der Client oder das Ziel keine Jumbo-Frames unterstützt.

Wenn ein Host ein Paket sendet, das größer als die MTU des empfangenden Hosts ist bzw. das größer als die MTU eines Geräts auf dem Pfad ist, löscht der empfangende Host bzw. das Gerät das Paket und gibt dann die folgende ICMP-Meldung zurück: Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4). Dies weist den übertragenden Host an, die Nutzlast in mehrere kleinere Pakete aufzuteilen und diese erneut zu übertragen.

Wenn Pakete, die größer als die MTU-Größe der Client- oder Zielschnittstelle sind, weiterhin gelöscht werden, funktioniert die Path MTU Discovery (PMTUD) wahrscheinlich nicht. Um dies zu vermeiden, stellen Sie sicher, dass die Path MTU Discovery durchgängig funktioniert und dass Sie Jumbo-Frames für Ihre Clients und Ziele aktiviert haben. Weitere Informationen zu Path MTU Discovery und zur Aktivierung von Jumbo Frames finden Sie unter Path MTU Discovery im EC2 Amazon-Benutzerhandbuch.