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.

Elastic Load Balancing unterstützt die folgenden Load-Balancer-Typen:

• Application Load Balancer

• Network Load Balancers

• Gateway Load Balancer

• Classic Load Balancer

Es gibt einen entscheidenden Unterschied in der Konfiguration der Load Balancer-Typen. Bei Application Load Balancern, Network Load Balancern und Gateway Load Balancern registrieren Sie Ziele in Zielgruppen und leiten Datenverkehr an die Zielgruppen weiter. Bei Classic Load Balancern registrieren Sie Instances direkt beim Load Balancer.

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

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. Bei Verwendung von API oder CLI ist der zonenübergreifende Load Balancing standardmäßig deaktiviert. Bei der AWS Management Console Option ist die 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. ARCerzeugt 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 How a Zonal Shift Works: Health Checks and Zonal IP Addresses im Amazon Application Recovery Controller (ARC) Developer Guide.

Bevor Sie die Zonenverschiebung verwenden, sollten Sie Folgendes beachten:

• Zonal Shift wird nicht unterstützt, wenn Sie einen Application Load Balancer mit aktiviertem zonenübergreifendem Load Balancing verwenden. 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, 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 Best Practices with Route 53 ARC Zonal Shifts im Amazon Application Recovery Controller (ARC) Developer Guide.

Weiterleitung von Anforderungen

Bevor ein Client eine Anfrage an Ihren Load Balancer sendet, löst er den Domainnamen des Load Balancers mithilfe eines Domain Name System () -Servers auf. DNS Der DNS Eintrag wird von Amazon kontrolliert, da sich Ihre Load Balancer in der amazonaws.com Domain befinden. Die DNS Amazon-Server geben eine oder mehrere IP-Adressen 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.

Wenn sich der Traffic zu Ihrer Anwendung im Laufe der Zeit ändert, skaliert Elastic Load Balancing Ihren Load Balancer und aktualisiert den DNS Eintrag. Der DNS Eintrag gibt auch den Wert 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 Load ELB Balancer im Amazon Route 53-Entwicklerhandbuch.

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

   • Die TCP Sequenznummer

2. Leitet jede einzelne TCP Verbindung für die gesamte Lebensdauer der Verbindung an ein einzelnes Ziel weiter. Die TCP Verbindungen von einem Client haben unterschiedliche Quellports und Sequenznummern und können an verschiedene Ziele weitergeleitet werden.

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

• Verwendet den Round-Robin-Routing-Algorithmus für TCP Listener

• Verwendet den Routing-Algorithmus für die wenigsten ausstehenden Anfragen für HTTP und HTTPS Listener

HTTPVerbindungen

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 Verbindungsmultiplexing zu verhindern, deaktivieren Sie HTTP keep-alive Header, indem Sie den Connection: close Header in Ihren Antworten festlegen. HTTP

Application Load Balancers und Classic Load Balancers unterstützen Pipelines auf Frontend-Verbindungen. HTTP Sie unterstützen keine HTTP Pipeline-On-Backend-Verbindungen.

Application Load Balancers unterstützen die folgenden HTTP Anforderungsmethoden:GET,,HEAD,POST, PUTDELETE, OPTIONS und. PATCH

Application Load Balancers unterstützen die folgenden Protokolle auf Frontend-Verbindungen: HTTP /0.9, HTTP /1.0, /1.1 und /2. HTTP HTTP Sie können HTTP /2 nur mit HTTPS Listenern verwenden und über eine HTTP /2-Verbindung bis zu 128 Anfragen parallel senden. Application Load Balancers unterstützen auch Verbindungsaktualisierungen von bisHTTP. 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 g an die Ziele zu senden. RPC Weitere Informationen finden Sie unter Protokollversionen. Der keep-alive-Header wird bei Backend-Verbindungen standardmäßig unterstützt. Für HTTP /1.0-Anfragen von Clients, die keinen Host-Header haben, generiert der Load Balancer einen Host-Header für die HTTP /1.1-Anfragen, 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 für Frontend-Verbindungen (Client zu Load Balancer): HTTP /0.9, /1.0 und /1.1. HTTP HTTP Sie verwenden HTTP /1.1 für Backend-Verbindungen (Load Balancer zum registrierten Ziel). Der keep-alive-Header wird bei Backend-Verbindungen standardmäßig unterstützt. Für HTTP /1.0-Anfragen von Clients, die keinen Host-Header haben, generiert der Load Balancer einen Host-Header für die HTTP /1.1-Anfragen, die über die Backend-Verbindungen gesendet werden. Der Host-Header enthält die IP-Adresse des Load-Balancer-Knotens.

HTTPHeader

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.

Bei Frontend-Verbindungen, die HTTP /2 verwenden, werden die Header-Namen in Kleinbuchstaben geschrieben. Bevor die Anforderung mit HTTP /1.1 an das Ziel gesendet wird, werden die folgenden Header-Namen in Groß- und Kleinschreibung umgewandelt: 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 /1.1 verwenden, einen Expect: 100-Continue Header erhalten, antworten sie sofort mit HTTP /1.1 100 Continue, ohne den Content Length-Header zu testen. HTTP 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 seine Ziele weiterleiten.

HTTPHeader-Grenzwerte

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 kann öffentlich in die öffentlichen IP-Adressen der Knoten aufgelöst werden. 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 kann öffentlich in die privaten IP-Adressen der Knoten aufgelöst werden. Daher können interne Load Balancer nur Anfragen von Clients weiterleiten, die Zugriff auf den VPC Load Balancer haben.

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.

• IPv4nur — 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 habenIPv4. 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 habenIPv4. 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)	IPv4nur	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.

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

• IPv6nur — 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	IPv4nur	IPv6nur
HTTPund HTTPS	Ja	Ja
TCP	Ja	Ja
TLS	Ja	Ja
UDPund TCP _ UDP	Ja	Ja
GENEVE	-	-

Netzwerk MTU für Ihren Load Balancer

Die maximale Übertragungseinheit (MTU) bestimmt die Größe in Byte für das größte Paket, das über das Netzwerk gesendet werden kann. Je MTU größer eine Verbindung ist, desto mehr Daten können in einem einzigen Paket übertragen werden. Ethernet-Rahmen bestehen aus dem Paket, also den eigentlichen Daten, die Sie senden, sowie aus den dazugehörigen Netzwerk-Overhead-Informationen. Der über ein Internet-Gateway gesendete Verkehr hat einen MTU Wert 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 der Load Balancer-Knoten ist nicht konfigurierbar. Jumbo Frames (9001MTU) sind Standard für alle Load Balancer-Knoten für Application Load Balancer, Network Load Balancer und Classic Load Balancer. Gateway Load Balancers unterstützen 8500. MTU Weitere Informationen finden Sie unter Maximale Übertragungseinheit (MTU) im Benutzerhandbuch für Gateway Load Balancers.

Der Pfad MTU ist die maximale Paketgröße, die auf dem Pfad zwischen dem ursprünglichen Host und dem empfangenden Host unterstützt wird. Path MTU Discovery (PMTUD) wird verwendet, um den Pfad MTU zwischen zwei Geräten zu bestimmen. 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 das MTU des empfangenden Hosts oder größer als das MTU eines Geräts auf dem Pfad ist, verwirft der empfangende Host oder das empfangende 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 verworfen werden, ist es wahrscheinlich, dass Path MTU Discovery (PMTUD) nicht funktioniert. Um dies zu vermeiden, stellen Sie sicher, dass Path MTU Discovery durchgängig funktioniert und dass Sie Jumbo Frames auf Ihren Clients und Zielen aktiviert haben. Weitere Informationen zu Path MTU Discovery und zur Aktivierung von Jumbo Frames finden Sie unter Path MTU Discovery im EC2Amazon-Benutzerhandbuch.