Elastic Load Balancing – Häufig gestellte Fragen

Ein Application Load Balancer kann auf allen Betriebssystemen ausgeführt werden, die aktuell vom Amazon EC2-Service unterstützt werden.

Ein Application Load Balancer unterstützt die Lastverteilung von Anwendungen, die HTTP- und HTTPS (Secure HTTP)-Protokolle verwenden.

Ja. Der HTTP/2-Support ist standardmäßig auf einem Application Load Balancer aktiviert. Clients, die HTTP/2 unterstützen, können sich über TLS mit einem Application Load Balancer verbinden.

Sie können den Datenverkehr von Ihrem Network Load Balancer, der Unterstützung für PrivateLink und eine statische IP-Adresse pro Availability Zone bietet, an Ihren Application Load Balancer weiterleiten. Erstellen Sie eine Zielgruppe vom Typ Application Load Balancer, registrieren Sie Ihren Application Load Balancer darin und konfigurieren Sie Ihre Netzwerklastverteilung so, dass sie den Verkehr an die Zielgruppe vom Typ Application Load Balancer weiterleitet.

Sie können für folgende TCP-Ports eine Lastverteilung durchführen: 1-65535

Ja. WebSockets- und Secure WebSockets-Support steht nativ auf einem Application Load Balancer zur Verfügung und kann sofort verwendet werden.

Ja. Die Anforderungsnachverfolgung ist standardmäßig auf Ihrem Application Load Balancer aktiviert.

Es gibt zwar Überschneidungen, aber die beiden Load-Balancer-Typen haben nicht denselben Features-Umfang. Application Load Balancers bilden in Zukunft das Grundgerüst unserer Lastverteilungsplattformen auf Anwendungsebene.

Ja.

Ja.

Nein. Application Load Balancer erfordern einen neuen Satz von Anwendungsprogrammierschnittstellen (APIs).

Über die ELB Console können Sie Application und Classic Load Balancers über eine einzige Schnittstelle verwalten. Wenn Sie das CLI oder ein SDK verwenden, werden Sie einen anderen "Service" für Application Load Balancers verwenden. Zum Beispiel beschreiben Sie im CLI Ihren Classic Load Balancer mit "aws elb describe-load-balancers" und Ihre Application Load Balancers mit "aws elbv2 describe-load-balancers".

Nein, ein bestimmter Typ von Load Balancer kann nicht in einen anderen Typen umgewandelt werden.

Ja. Für die Migration von einem Classic Load Balancer auf einen Application Load Balancer stehen Ihnen die in diesem Dokument genannten Optionen zur Verfügung.

Nein. Wenn Sie Layer-4-Eigenschaften benötigen, sollten Sie einen Network Load Balancer verwenden.

Ja, Sie können den HTTP-Port 80 und den HTTPS-Port 443 einem einzelnen Application Load Balancer zuordnen.

Ja. Mit AWS CloudTrail können Sie den Verlauf der auf Ihrem Konto getätigten API-Aufrufe für Application Load Balancing abrufen.

Ja, Sie können eine HTTPS-Verbindung auf dem Application Load Balancer terminieren. Sie müssen ein Secure-Sockets-Layer (SSL)-Zertifikat auf dem Load Balancer installieren. Der Load Balancer verwendet dieses Zertifikat, um die Verbindung zu beenden und dann Anforderungen von Clients zu entschlüsseln, bevor sie an die Ziele gesendet werden.

Sie können AWS Certificate Manager verwenden, um ein SSL/TLS-Zertifikat bereitzustellen, oder Sie können das Zertifikat aus anderen Quellen abrufen, indem Sie die Zertifikatsanforderung erstellen, die von der CA signierte Zertifikatsanforderung abrufen und das Zertifikat dann entweder mit dem AWS Certification Manager oder dem AWS Identity and Access Management (IAM)-Service hochladen.

Ein Application Load Balancer ist bereits in AWS Certificate Management (ACM) integriert. Durch die Integration in ACM wird das Binden eines Zertifikats an den Load Balancer und damit der gesamte SSL-Entladeprozess sehr einfach. Das Kaufen, Hochladen und Erneuern von SSL/TLS-Zertifikaten ist ein zeitaufwändiger manueller und komplexer Prozess. Dadurch, dass ACM im Application Load Balancer integriert ist, wurde dieser gesamte Prozess auf das einfache Anfordern eines vertrauenswürdigen SSL/TLS-Zertifikats und das Auswählen des ACM-Zertifikats für die Bereitstellung mit dem Load Balancer verkürzt.

Nein, bei einem Application Load Balancer wird im Back-End nur die Verschlüsselung unterstützt.

SNI wird automatisch aktiviert, wenn Sie demselben sicheren Listener in einem Load Balancer mehr als ein TLS-Zertifikat zuweisen. Gleichermaßen wird der SNI-Modus für einen sicheren Listener automatisch deaktiviert, wenn Sie diesem nur ein Zertifikat zugewiesen haben.

Ja. Sie können einem sicheren Listener mehrere Zertifikate für dieselbe Domain zuweisen. Zum Beispiel können Sie Folgendes zuweisen:

• ECDSA- und RSA-Zertifikate
• Zertifikate mit unterschiedlichen Schlüssellängen (z. B. 2 000 und 4 000) für SSL-/TLS-Zertifikate
• Zertifikate für eine einzelne Domäne, mehrere Domänen (SAN) und Platzhalter

Ja, IPv6 wird von einem Application Load Balancer unterstützt.

Sie können Regeln für jeden Listener im Load Balancer konfigurieren. Die Regeln beinhalten Bedingungen und die dazugehörigen Aktionen, wenn die Bedingungen erfüllt werden. Die unterstützten Bedingungen sind Host-Header, Pfad, HTTP-Header, Methoden, Abfrageparameter und Quell-IP-classless-inter-domain-routings (CIDR). Die unterstützten Aktionen sind Umleitung, feste Antwort, Authentifizierung und Weiterleitung. Sobald Sie dies eingerichtet haben, bestimmt der Load Balancer anhand der Regeln, wie eine bestimmte HTTP-Anfrage weitergeleitet werden soll. Sie können mehrere Bedingungen und Aktionen in einer Regel verwenden und in jeder Bedingung eine Übereinstimmung für mehrere Werte angeben.

Die Beschränkungen für einen Application Load Balancer können Sie Ihrem AWS-Konto entnehmen.

Sie können Ihren Application Load Balancer mit der AWS Web Application Firewall (WAF) integrieren. Dies ist eine Webanwendungs-Firewall zum Schutz von Webanwendungen vor Angriffen. Dafür konfigurieren Sie Regeln auf der Grundlage von IP-Adressen, HTTP-Kopfzeilen und benutzerdefinierten URI-Zeichenfolgen. Anhand dieser Regeln kann AWS WAF Webanforderungen an Ihre Webanwendung blockieren, zulassen oder überwachen (zählen). Weitere Informationen finden Sie im AWS-WAF-Entwicklerhandbuch.

Sie können eine beliebige IP-Adresse aus dem VPC CIDR des Load Balancers für Ziele innerhalb der VPC des Load Balancers und eine beliebige IP-Adresse aus den RFC 1918-Bereichen (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16) oder dem RFC 6598-Bereich (100.64.0.0/10) für Ziele außerhalb der VPC des Load Balancers verwenden (zum Beispiel Ziele in gleichgeschalteten VPCs, Amazon-EC2-Classic und an On-Premises-Standorten, die über AWS Direct Connect oder eine VPN-Verbindung erreichbar sind).

Es gibt verschiedene Möglichkeiten für einen Hybrid-Lastausgleich. Wenn eine Anwendung auf Zielen ausgeführt wird, die zwischen einer VPC und einem lokalen Standort verteilt sind, können Sie sie mithilfe ihrer IP-Adressen der gleichen Zielgruppe hinzufügen. Um eine Migration zu AWS ohne Auswirkungen auf Ihre Anwendung durchzuführen, fügen Sie der Zielgruppe nach und nach VPC-Ziele hinzu und entfernen lokale Ziele aus der Zielgruppe. 

Wenn Sie zwei unterschiedliche Anwendungen haben, bei denen sich die Ziele einer Anwendung in einer VPC und die Ziele der anderen Anwendung an einem lokalen Standort befinden, können Sie die VPC-Ziele in einer Zielgruppe und die lokalen Ziele in einer anderen Zielgruppe platzieren und inhaltsbasiertes Routing verwenden, um Datenverkehr an die einzelnen Zielgruppen umzuleiten. Außerdem können die separate Load Balancers für VPC- und lokale Ziele sowie DNS-Gewichtung verwenden, um einen gleichmäßigen Lastausgleich zwischen VPC- und lokalen Zielen zu erreichen.

Ein Lastausgleich für EC2-Classic-Instanzen kann nicht durchgeführt werden, wenn ihre Instance-IDs als Ziele registriert sind. Wenn Sie allerdings diese EC2-Classic-Instanzen über ClassicLink mit der VPC des Lastenausgleichs verknüpfen und die privaten IP-Adressen dieser EC2-Classic-Instances als Ziele verwenden, können Sie einen Lastausgleich für die EC2-Classic-Instanzen durchführen. Wenn Sie EC2 Classic-Instanzen heute mit einem Classic Load Balancer verwenden, können Sie problemlos eine Migration zu einem Application Load Balancer durchführen.

Die zonenübergreifende Lastverteilung ist in Application Load Balancer standardmäßig aktiviert.

In diesen Fällen sollte die Authentifizierung durch Amazon Cognito erfolgen:

• Sie möchten Ihren Benutzern die Flexibilität bieten, ihre Authentifizierung entweder anhand von sozialen Netzwerkidentitäten (Google, Facebook und Amazon) oder Unternehmensidentitäten (SAML) bzw. anhand Ihrer eigenen, vom Amazon Cognito Benutzerpool bereitgestellten Benutzerverzeichnisse durchzuführen.
• Sie verwalten mehrere Identitätsanbieter einschließlich OpenID Connect und möchten eine einzige Authentifizierungsregel in Application Load Balancer (ALB) erstellen, mit der Ihre Identitätsanbieter durch Amazon Cognito verbunden werden können.
• Sie müssen Benutzerprofile mit einem oder mehreren sozialen oder OpenID Connect-Identitätsanbietern von einem zentralen Ort aus aktiv verwalten. So können Sie beispielsweise Benutzer in Gruppen unterteilen und benutzerspezifische Attribute hinzufügen, um den Benutzerstatus darzustellen und den Zugriff der bezahlenden Benutzer zu kontrollieren.

Wenn Sie allerdings bereits in die Entwicklung von benutzerspezifischen IdP-Lösungen investiert haben und einfach nur eine Authentifizierung durch einen einzigen OpenID-Connect-konformen Identitätsanbieter suchen, spricht Sie die native OIDC-Lösung von Application Load Balancer vielleicht eher an.

Die folgenden drei Arten von Umleitungen werden unterstützt.

HTTP zu HTTP
http://hostA zu http://hostB

HTTP zu HTTPS
http://hostA zu https://hostB
https://hostA:portA/pfadA zu https://hostB:portB/pfadB

HTTPS zu HTTPS
https://hostA zu https://hostB

Die folgenden Arten von Inhalten werden unterstützt: Text/einfach, Text/CSS, Text/HTML, Anwendung/Javascript, Anwendung/JSON.

Von einem Load Balancer empfangene HTTP(S)-Anforderungen werden mit den inhaltsbasierten Routing-Regeln verarbeitet. Wenn der angeforderte Inhalt mit einer Regel übereinstimmt, deren Aktion aus der Weiterleitung des Inhalts an eine Zielgruppe mit einer Lambda-Funktion als Ziel besteht, wird die entsprechende Lambda-Funktion aufgerufen. Der Inhalt der Anforderung (einschließlich Header und Inhalt) wird im JSON-Format in JavaScript an die Lambda-Funktion weitergeleitet. Die Antwort der Lambda-Funktion sollte im JSON-Format erfolgen. Die Antwort der Lambda-Funktion wird in eine HTTP-Antwort umgewandelt und an den Client gesendet. Der Load Balancer ruft Ihre Lambda-Funktion mithilfe der Aufruf-API von AWS Lambda auf und erfordert, dass Sie Ihrer Lambda-Funktion Aufruf-Berechtigungen an den Elastic Load Balancing-Service erteilt haben.

Ja. Der Application Load Balancer unterstützt Lambda-Aufrufe für Anforderungen über das HTTP- und das HTTPS-Protokoll.

Sie können Lambda als Ziel mit dem Application Load Balancer in folgenden AWS-Regionen verwenden: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Nordkalifornien), USA West (Oregon), Asien-Pazifik (Mumbai), Asien-Pazifik (Seoul), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Kanada (Zentral), EU (Frankfurt), EU (Irland), EU (London), EU (Paris), Südamerika (São Paulo) und GovCloud (USA West).

Ja, Application Load Balancer ist in der Local Zone in Los Angeles verfügbar. In der lokalen Zone von Los Angeles operiert der Application Load Balancer in einem einzelnen Subnetz und skaliert automatisch, um verschiedenen Stufen an Anwendungsbelastung ohne manuelle Eingriffe entgegenzukommen.

Der Endpreis setzt sich daraus zusammen, wie lange Sie einen Application Load Balancer ausführen (entweder für jede volle oder für jede angebrochene Stunde) und wie viele Load Balancer Capacity Units (LCU) Sie pro Stunde verwenden.

Eine LCU ist eine neue Metrik zur Preisberechnung für einen Application Load Balancer. Eine LCU bestimmt die maximale Ressourcenauslastung in einer der Dimensionen (neue Verbindungen, aktive Verbindungen, Bandbreite und Regelauswertungen), in der der Application Load Balancer Ihren Datenverkehr verarbeitet.

Nein, bei Classic Load Balancers werden Ihnen nach wie vor nur die genutzte Bandbreite und ein Stundensatz berechnet.

Wir stellen über Amazon CloudWatch die Nutzung aller vier Dimensionen bereit, die eine LCU bilden.

Nein. Die Anzahl der LCUs pro Stunde hängt von der maximalen Ressourcenauslastung in den vier Dimensionen ab, die eine LCU ausmachen.

Ja.

Ja. Neue AWS-Kunden können ein kostenloses Kontingent für einen Application Load Balancer nutzen, das 750 Stunden und 15 LCUs umfasst. Dieses Angebot für kostenlose Kontingente steht nur neuen AWS-Kunden zur Verfügung und ist für einen Zeitraum von 12 Monaten ab Ihrer AWS-Registrierung gültig.

Ja. Sie können sowohl Classic als auch Application Load Balancer für je 15 GB und 15 LCUs nutzen. Die 750 Load Balancer-Stunden gelten allerdings für Classic und Application Load Balancer gemeinsam.

Regelauswertungen werden als Durchschnittsergebnis der verarbeiteten Anzahl an Regeln und der Anforderungsrate pro Stunde definiert.

Die Schlüssellänge der Zertifikate beeinflusst ausschließlich die Anzahl der neuen Verbindungen pro Sekunde in der LCU-Berechnung für die Abrechnung. Die folgende Tabelle führt den Wert der unterschiedlichen Schlüssellängen für RSA- und ECDSA-Zertifikate auf.

RSA-Zertifikate
Schlüssellänge: < = 2 KB 
Neue Verbindungen/Sekunde: 25

Schlüssellänge: < = 4 K 
Neue Verbindungen/Sekunde: 5

Schlüssellänge: < = 8 K 
Neue Verbindungen/Sekunde: 1

Schlüssellänge: > 8 K
Neue Verbindungen/Sekunde: 0,25

ECDSA-Zertifikate
Schlüssellänge: < = 256
Neue Verbindungen/Sekunde: 25

Schlüssellänge: < = 384
Neue Verbindungen/Sekunde: 5

Schlüssellänge: < = 521 
Neue Verbindungen/Sekunde: 1

Schlüssellänge: > 521 
Neue Verbindungen/Sekunde: 0,25

Nein. Da die zonenübergreifende Lastverteilung in Application Load Balancer immer aktiviert ist, fallen für diese Art der regionalen Datenübertragung keine Gebühren an.

Nein. Für die Aktivierung der Authentifizierungsfunktion in Application Load Balancer entfällt keine separate Gebühr. Wenn Amazon Cognito mit Application Load Balancer verwendet wird, gelten die Preise für Amazon Cognito.

Der Endpreis setzt sich wie üblich daraus zusammen, wie lange Sie einen Application Load Balancer ausführen (entweder für jede volle oder für jede angebrochene Stunde) und wie viele Load Balancer Capacity Units (LCU) Sie pro Stunde verwenden. Für Lambda-Ziele bietet jede LCU 0,4 verarbeitete GB pro Stunde, 25 neue Verbindungen pro Sekunde, 3 000 aktive Verbindungen pro Minute und 1 000 Regelauswertungen pro Sekunde. In Hinblick auf die Menge der verarbeiteten Bytes-Dimension bietet LCU 0,4 GB pro Stunde für Lambda-Ziele im Vergleich zu 1 GB pro Stunde für alle anderen Zieltypen wie Amazon-EC2-Instances, Container und IP-Adressen. Beachten Sie, dass die üblichen AWS Lambda-Gebühren für Lambda-Aufrufe durch den Application Load Balancer gelten.

Application Load Balancer geben zwei neue CloudWatch-Metriken aus. Die LambdaTargetProcessedBytes-Metrik gibt die von Lambda-Zielen verarbeiteten Bytes an und die StandardProcessedBytes-Metrik gibt die von allen anderen Zielarten verarbeiteten Bytes an.

Ja. Network Load Balancer unterstützen sowohl Listener für TCP, UDP und TCP+UDP (Layer 4) als auch TLS-Listener.

Der Network Load Balancer unterstützt sowohl den Lastausgleich für TCP als auch für UDP (Ebene 4). Er ist für die Verarbeitung von Millionen von Anforderungen pro Sekunde sowie einen schwankenden Webdatenverkehr und niedrige Latenzen konzipiert. Darüber hinaus unterstützt Network Load Balancer auch die TLS-Terminierung, bewahrt die Quell-IP der Clients und bietet stabile IP-Unterstützung und zonale Isolation. Er unterstützt zudem langlaufende Verbindungen, die sehr nützlich für WebSocket-Anwendungen sind.

Ja. Dazu können Sie einen TCP+UDP-Listener verwenden. Beispielsweise können Sie für einen DNS-Service, der sowohl das TCP- als auch das UDP-Protokoll verwendet, einen TCP+UDP-Listener an Port 53 erstellen. Der Load Balancer verarbeitet dann an diesem Port Datenverkehr sowohl für UDP- als auch für TCP-Anforderungen. Einer TCP+UDP-Zielgruppe müssen Sie einen TCP+UDP-Listener zuordnen.

Der Network Load Balancer behält die IP-Quelladresse der Clients bei. Dies ist beim Classic Load Balancer nicht der Fall. Kunden können Proxy Control mit dem Classic Load Balancer, um die IP-Quelladresse abzurufen. Der Network Load Balancer teilt dem Load Balancer automatisch eine statische IP-Adresse pro Availability Zone (AZ) zu und ermöglicht zudem die Zuteilung einer elatischen IP-Adresse pro AZ an den Load Balancer. Diese Funktion wird vom Classic Load Balancer nicht unterstützt.

Ja. Für die Migration von einem Classic Load Balancer auf einen Network Load Balancer stehen Ihnen die in diesem Dokument genannten Optionen zur Verfügung.

Ja. Lesen Sie für weitere Informationen die Dokumentation zu Beschränkungen für Network Load Balancer.

Ja, Sie können die AWS-Managementkonsole, AWS CLI oder API verwenden, um einen Network Load Balancer einzurichten.

Nein. Um einen Classic Load Balancer zu erstellen, verwenden Sie die API 2012-06-01. Um einen Network Load Balancer oder einen Application Load Balancer zu erstellen, verwenden Sie die API 2015-12-01.

Ja, Sie können Ihren Network Load Balancer in einer einzigen AZ erstellen, indem Sie bei der Erstellung des Load Balancers nur ein Subnetz angeben.

Ja, Sie können die Zustandsprüfungs- und DNS Failover-Funktionen von Amazon Route 53 verwenden, um die Verfügbarkeit der Anwendungen, die hinter Network Load Balancers laufen, zu erhöhen. Durch die Verwendung von Route 53 DNS Failover können Sie Anwendungen in mehreren AWS Availability Zones ausführen und alternative Load Balancers für Failover in den verschiedenen Regionen bestimmen. 

Wenn Sie Ihren Network Load Balancer für mehrere AZ konfiguriert haben und für diese AZ keine fehlerfreien EC2-Instances beim Load Balancer registriert wurden oder die Knoten des Load Balancers für eine bestimmte Zone fehlerhaft sind, lässt Route 53 mit der Ausführung alternativer Knoten des Load Balancers in anderen fehlerfreien AZ nach.

Nein. Die Adresse eines Network Load Balancers muss entweder vollständig von Ihnen oder vollständig vom Elastic Load Balancer kontrolliert werden. Auf diese Weise wird sichergestellt, dass sich bei der Verwendung von elastischen IP-Adressen bei einem Network Load Balancer keine ihren Clients bekannte IP-Adresse ändert.

Nein. Für jedes Subnetz, dem ein Network Load Balancer zugewiesen wurde, unterstützt der Network Load Balancer nur eine einzelne öffentliche oder Internet-IP-Adresse.

Die Elastic-IP-Adressen, die Ihrem Load Balancer zugewiesen waren, werden erneut Ihrem entsprechenden Pool zugeordnet und stehen für zukünftige Verwendungen zur Verfügung.

Der Network Load Balancer kann als Load Balancer mit Internetverbindung oder als interner Load Balancer eingerichtet werden. Ähnliches gilt für den Application Load Balancer und den Classic Load Balancer.

Nein. Für jedes Subnetz, dem ein Load Balancer zugewiesen wurde, unterstützt der Network Load Balancer nur eine private IP-Adresse.

Ja, konfigurieren Sie TCP-Listeners so, dass diese den Datenverkehr zu den Zielen leiten, die ein WebSockets-Protokoll implementieren (https://tools.ietf.org/html/rfc6455). Da WebSockets ein Layer 7-Protokoll ist und der Network Load Balancer mit Layer 4 arbeitet, ist für den Network Load Balancer kein besonderes Verfahren für WebSockets oder andere Protokolle einer höheren Stufe verfügbar.

Ja. Sie können eine beliebige IP-Adresse aus dem VPC CIDR des Load Balancers für Ziele innerhalb der VPC des Load Balancers und eine beliebige IP-Adresse aus den RFC 1918-Bereichen (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16) oder dem RFC 6598-Bereich (100.64.0.0/10) für Ziele verwenden, die sich außerhalb der VPC des Load Balancers befinden (EC2-Classic und an lokalen Standorten, die über AWS Direct Connect erreichbar sind). Der Lastausgleich für Ziele mit IP-Adressen wird derzeit nur bei TCP-Listenern, nicht jedoch bei UDP-Listenern unterstützt.

Ja. Network Load Balancer mit TCP- und TLS-Listenern können zur Einrichtung von AWS PrivateLink verwendet werden. Mit UDP-Listenern ist die Einrichtung von PrivateLink bei Network Load Balancern hingegen nicht möglich.

UDP an sich erfolgt zwar verbindungslos. Jedoch verfolgt der Load Balancer den UDP-Datenflussstatus auf Basis eines 5-Tuple-Hash, durch das sichergestellt wird, dass im selben Kontext gesendete Pakete durchgehend dem gleichen Ziel zugestellt werden. Der Datenfluss gilt als aktiv, so lange der Datenverkehr fließt und das Leerlauf-Zeitlimit noch nicht erreicht ist. Bei Erreichen dieses Zeitlimits vergisst der Load Balancer diese Zugehörigkeit, d. h., neu eingehende UDP-Pakete werden als neuer Datenfluss betrachtet und an ein anderes Ziel verteilt.

Das Leerlauf-Zeitlimit des Network Load Balancer für TCP-Verbindungen beträgt 350 Sekunden. Das Leerlauf-Zeitlimit für UDP-Datenflüsse ist dagegen 120 Sekunden.

Jeder Container in einer Instance kann jetzt über eine eigene Sicherheitsgruppe verfügen und muss keine Sicherheitsregeln mit anderen Containern teilen. Sie können Sicherheitsgruppen an eine ENI anfügen und jede ENI auf einer Instance kann eine andere Sicherheitsgruppe haben. Sie können der IP-Adresse einer bestimmten ENI einen Container zuordnen, um Sicherheitsgruppen pro Container zuzuweisen. Der Lastausgleich über IP-Adressen ermöglicht außerdem, dass mehrere Container, die auf einer Instance ausgeführt werden, den gleichen Port (etwa Port 80) verwenden. Die Möglichkeit, den gleichen Port für mehrere Container zu verwenden, ermöglicht Containern auf einer Instanz die gegenseitige Kommunikation über bekannte anstatt über zufällige Ports.

Es gibt verschiedene Möglichkeiten für einen Hybrid-Lastausgleich. Wenn eine Anwendung auf Zielen ausgeführt wird, die zwischen einer VPC und einem lokalen Standort verteilt sind, können Sie sie mithilfe ihrer IP-Adressen der gleichen Zielgruppe hinzufügen. Um eine Migration zu AWS ohne Auswirkungen auf Ihre Anwendung durchzuführen, fügen Sie der Zielgruppe nach und nach VPC-Ziele hinzu und entfernen lokale Ziele aus der Zielgruppe. Außerdem können die separate Load Balancers für VPC- und lokale Ziele sowie DNS-Gewichtung verwenden, um einen gleichmäßigen Lastausgleich zwischen VPC- und lokalen Zielen zu erreichen.

Ein Lastausgleich für EC2-Classic-Instanzen kann nicht durchgeführt werden, wenn ihre Instance-IDs als Ziele registriert sind. Wenn Sie allerdings diese EC2-Classic-Instanzen über ClassicLink mit der VPC des Lastenausgleichs verknüpfen und die privaten IP-Adressen dieser EC2-Classic-Instances als Ziele verwenden, können Sie einen Lastausgleich für die EC2-Classic-Instanzen durchführen. Wenn Sie EC2 Classic-Instances heute mit einem Classic Load Balancer verwenden, können Sie problemlos eine Migration zu einem Network Load Balancer durchführen.

Die zonenübergreifende Lastverteilung können Sie erst nach der Erstellung Ihres Network Load Balancer aktivieren. Hierzu bearbeiten Sie den Abschnitt mit den Load-Balancer-Attributen und aktivieren dann das Kontrollkästchen für die Unterstützung des Lastausgleichs über mehrere Zonen.

Ja. Bei Verwendung des Network Load Balancer fallen für regionale Datenübertragungen zwischen Availability Zones Gebühren an, wenn die zonenübergreifende Lastverteilung aktiviert ist. Die Gebühren entnehmen Sie bitte dem Abschnitt „Datenübertragung“ auf der Seite mit den Preisen für Amazon-EC2-On-Demand.

Ja. Network Load Balancer unterstützt derzeit 200 Ziele pro Availability Zone. Arbeiten Sie beispielsweise in zwei AZ, so können Sie in Network Load Balancer bis zu 400 Ziele registrieren. Bei aktivierter zonenübergreifender Lastverteilung reduziert sich die Zahl Ihrer Ziele jedoch von 200 Zielen pro Availability Zone auf 200 Ziele pro Load Balancer. Wenn also im obigen Beispiel die zonenübergreifende Lastverteilung aktiviert ist, können Sie, obwohl Ihr Load Balancer in zwei AZ ist, nur maximal 200 Ziele für Ihren Load Balancer registrieren.

Ja, Sie können TLS-Verbindungen auf dem Network Load Balancer beenden. Sie müssen ein SSL-Zertifikat auf dem Load Balancer installieren. Der Load Balancer verwendet dieses Zertifikat, um die Verbindung zu beenden und dann Anforderungen von Clients zu entschlüsseln, bevor sie an die Ziele gesendet werden.

Die Quell-IP bleibt auch dann erhalten, wenn Sie TLS im Network Load Balancer beenden.

Sie können entweder AWS Certificate Manager verwenden, um ein SSL/TLS-Zertifikat bereitzustellen, oder Sie können das Zertifikat aus anderen Quellen abrufen, indem Sie die Zertifikatsanforderung erstellen, die von der CA signierte Zertifikatsanforderung abrufen und das Zertifikat dann entweder mit dem AWS Certification Manager (ACM) oder dem AWS Identity and Access Management (IAM)-Service hochladen.

SNI wird automatisch aktiviert, wenn Sie demselben sicheren Listener in einem Load Balancer mehr als ein TLS-Zertifikat zuweisen. Gleichermaßen wird der SNI-Modus für einen sicheren Listener automatisch deaktiviert, wenn Sie diesem nur ein Zertifikat zugewiesen haben.

Network Load Balancer ist in das AWS Certificate Management (ACM) integriert. Durch die Integration in ACM wird das Binden eines Zertifikats an den Load Balancer und damit der gesamte SSL-Entladeprozess sehr einfach. Das Kaufen, Hochladen und Erneuern von SSL/TLS-Zertifikaten ist ein zeitaufwändiger manueller und komplexer Prozess. Mit der ACM-Integration mit Network Load Balancer wurde dieser gesamte Prozess auf die einfache Anforderung eines vertrauenswürdigen SSL/TLS-Zertifikats und die Auswahl des ACM-Zertifikats für die Bereitstellung mit dem Load Balancer verkürzt. Nachdem Sie einen Network Load Balancer erstellt haben, können Sie nun einen TLS-Listener konfigurieren und haben dann die Möglichkeit, ein Zertifikat entweder aus ACM oder Identity Access Manager (IAM) auszuwählen. Diese Erfahrung ist ähnlich wie bei Application Load Balancer oder Classic Load Balancer.

Nein, mit Network Load Balancer wird nur die Backend-Verschlüsselung unterstützt.

Network Load Balancer unterstützt nur RSA-Zertifikate mit 2K-Schlüsselgröße. Wir unterstützen derzeit keine RSA-Zertifikatsschlüsselgrößen größer als 2K oder ECDSA-Zertifikate auf dem Network Load Balancer.

Sie können TLS-Terminierung auf dem Load Balancer in folgenden AWS-Regionen verwenden: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Nordkalifornien), USA West (Oregon), Asien-Pazifik (Mumbai), Asien-Pazifik (Seoul), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Kanada (Zentral), EU (Frankfurt), EU (Irland), EU (London), EU (Paris), Südamerika (São Paulo) und GovCloud (USA West).

Der Endpreis setzt sich daraus zusammen, wie lange Sie einen Network Load Balancer ausführen (entweder für jede volle oder für jede angebrochene Stunde) und wie viele Load Balancer Capacity Units (LCU) der Network Load Balancer pro Stunde verwendet.

Eine LCU ist eine neue Metrik zur Preisberechnung für einen Network Load Balancer. Eine LCU bestimmt die maximale Ressourcenauslastung in einer der Dimensionen (neue Verbindungen/Datenflüsse, aktive Verbindungen/Datenflüsse und Bandbreite), in der der Network Load Balancer den Datenverkehr verarbeitet.

Die LCU-Metriken für TCP-Datenverkehr lauten wie folgt:

• 800 neue TCP-Verbindungen pro Sekunde
• 100 000 aktive TCP-Verbindungen pro Minute
• 1 GB pro Stunde für Amazon-EC2-Instances, -Container und IP-Adressen als Ziele

Die LCU-Metriken für UDP-Datenverkehr lauten wie folgt:

• 400 neue Datenflüsse pro Sekunde
• 50 000 aktive UDP-Datenflüsse pro Minute
• 1 GB pro Stunde für Amazon-EC2-Instances, -Container und IP-Adressen als Ziele

Die LCU-Metriken für TLS-Datenverkehr lauten wie folgt:

• 50 neue TLS-Verbindungen pro Sekunde
• 3 000 aktive TLS-Verbindungen pro Minute
• 1 GB pro Stunde für Amazon-EC2-Instances, -Container und IP-Adressen als Ziele

Nein. Für jedes Protokoll wird Ihnen nur eine der drei Dimensionen in Rechnung gestellt (mit dem höchsten Wert pro Stunde).

Nein. Mehrere Anforderungen können innerhalb einer einzigen Verbindung gesendet werden.

Nein. Bei Classic Load Balancers werden Ihnen nach wie vor nur die genutzte Bandbreite und ein Stundensatz berechnet.

Genaue Daten zu allen drei Dimensionen, die eine LCU ausmachen, finden Sie auf Amazon CloudWatch.

Die Anzahl der LCUs pro Stunde hängt von der maximalen Ressourcenauslastung in den drei Dimensionen ab, die eine LCU ausmachen.

Ja.

Ja. Neue AWS-Kunden können ein kostenloses Kontingent für einen Network Load Balancer nutzen, das 750 Stunden und 15 LCUs umfasst. Dieses Angebot für kostenlose Kontingente steht nur neuen AWS-Kunden zur Verfügung und ist für einen Zeitraum von 12 Monaten ab Ihrer AWS-Registrierung gültig.

Ja. Sie können Application und Network Load Balancer jeweils für 15 LCUs und den Classic Load Balancer für 15 GB nutzen. Die 750 Load Balancer-Stunden gelten allerdings für Application, Network und Classic Load Balancer gemeinsam.

Sie sollten Gateway Load Balancer verwenden, wenn Sie virtuelle Inline-Appliances bereitstellen, bei denen der Netzwerkverkehr nicht für den Gateway Load Balancer selbst bestimmt ist. Gateway Load Balancer leitet den gesamten Layer-3-Datenverkehr transparent durch virtuelle Appliances von Drittanbietern und ist für die Quelle und das Ziel des Datenverkehrs unsichtbar. Weitere Einzelheiten zum Vergleich dieser Load Balancer finden Sie auf der Seite Features-Vergleich.

Gateway Load Balancer wird innerhalb einer AZ ausgeführt.

Gateway Load Balancer bietet sowohl Gateway-Funktionen auf Ebene 3 als auch Load-Balancer-Funktionen auf Ebene 4. Es ist ein transparentes Bump-In-the-Wire-Gerät, das keinen Teil des Pakets ändert. Es ist für die Verarbeitung von Millionen von Anforderungen pro Sekunde sowie einen schwankenden Webdatenverkehr und niedrige Latenzen konzipiert. Features von Gateway Load Balancer finden Sie in dieser Tabelle. 

Gateway Load Balancer führt keine TLS-Terminierung durch und behält keinen Anwendungsstatus bei. Diese Funktionen werden von den virtuellen Appliances von Drittanbietern ausgeführt, an die sie den Datenverkehr weiterleitet und von denen sie den Datenverkehr empfängt.

Gateway Load Balancer hält den Zustand der Anwendung nicht aufrecht, hält aber die Gebundenheit der Flüsse zu einer bestimmten Anwendung mit 5-Tupel (für TCP/UDP-Flüsse) oder 3-Tupel (für alle anderen Flüsse) aufrecht.

Gateway Load Balancer definiert standardmäßig einen Ablauf als eine Kombination aus einem 5-Tupel, das aus Quell-IP, Ziel-IP, IP-Protokoll, Quellport und Zielport besteht. Mithilfe des standardmäßigen 5-Tupel-Hash stellt Gateway Load Balancer sicher, dass beide Richtungen eines Ablaufs (d. h. Quelle zu Ziel und Ziel zu Quelle) konsistent an dasselbe Ziel weitergeleitet werden. Der Ablauf gilt als aktiv, so lange der Datenverkehr fließt und das Leerlauf-Timeout noch nicht erreicht ist. Sobald dieses Timeout erreicht ist, vergisst der Load Balancer diese Zugehörigkeit, d. h. neu eingehende Datenverkehr-Pakete werden als neuer Ablauf betrachtet und an ein anderes Ziel verteilt.

Die standardmäßige 5-Tupel-Stickiness (Quell-IP, Ziel-IP, IP-Protokoll, Quellport und Zielport) sorgt für die optimale Verteilung des Datenverkehrs an Ziele und ist mit einigen Ausnahmen für die meisten TCP- und UDP-basierten Anwendungen geeignet. Die standardmäßige 5-Tupel-Stickiness ist nicht für TCP- oder UDP-basierte Anwendungen geeignet, die separate Streams oder Portnummern für Steuerung und Daten verwenden, wie FTP, Microsoft RDP, Windows RPC und SSL VPN. Kontroll- und Datenflüsse solcher Anwendungen können auf verschiedenen Zielgeräten landen und zu Verkehrsstörungen führen. Wenn Sie solche Protokolle unterstützen möchten, sollten Sie die GWLB-Ablauf-Stickiness mithilfe von 3-Tupel (Quell-IP, Ziel-IP, IP-Protokoll) oder 2-Tupel (Quell-IP, Ziel-IP) aktivieren.

Einige Anwendungen verwenden überhaupt keinen TCP- oder UDP-Transport, sondern stattdessen IP-Protokolle wie SCTP und GRE. Mit der standardmäßigen 5-Tupel-Stickiness von GWLB können Datenströme aus diesen Protokollen auf verschiedenen Zielgeräten landen und zu Störungen führen. Wenn Sie solche Protokolle unterstützen möchten, sollten Sie die GWLB-Ablauf-Stickiness mithilfe von 3-Tupel (Quell-IP, Ziel-IP, IP-Protokoll) oder 2-Tupel (Quell-IP, Ziel-IP) aktivieren.

Informationen zum Ändern der Art der Ablauf-Stickiness finden Sie in der Dokumentation zur Ablauf-Stickiness.

Das Leerlauf-Zeitlimit des Gateway Load Balancers für TCP-Verbindungen beträgt 350 Sekunden. Das Leerlauf-Zeitlimit für Nicht-TCP-Datenflüsse ist dagegen 120 Sekunden. Diese Timeouts sind fix und können nicht geändert werden.

Als transparenter Bump-in-the-Wire fragmentiert GWLB selbst keine Pakete und setzt sie nicht wieder zusammen.

GWLB leitet UDP-Fragmente zu/von Zielgeräten weiter. GWLB löscht jedoch TCP- und ICMP-Fragmente, da in diesen Fragmenten kein Layer-4-Header vorhanden ist.

Wenn das Zielgerät außerdem das ursprüngliche eingehende Paket in Fragmente konvertiert und die neu erstellten Fragmente zurück an GWLB sendet, löscht GWLB diese neu erstellten Fragmente, da sie keinen Layer-4-Header enthalten. Um zu verhindern, dass auf dem Zielgerät Fragmentierung stattfindet, empfehlen wir, auf Ihrem Zielgerät Jumbo-Frame zu aktivieren, oder die Netzwerkschnittstelle des Zielgeräts so einzustellen, dass es die maximale erwünschte MTU nutzt. Dadurch wird eine transparente Weiterleitung erreicht, da der Originalinhalt des Pakets unverändert beibehalten wird. 

Wenn eine einzelne virtuelle Appliance-Instance ausfällt, entfernt Gateway Load Balancer sie aus der Routing-Liste und leitet den Datenverkehr auf eine gesunde Appliance-Instance um.

Wenn alle virtuellen Geräte innerhalb einer Availability Zone ausfallen, verwirft Gateway Load Balancer den Netzwerk-Datenverkehr. Wir empfehlen die Bereitstellung von Gateway Load Balancern in mehreren Availability Zones für eine höhere Verfügbarkeit. Wenn alle Geräte in einer AZ ausfallen, können Skripte verwendet werden, um entweder neue Geräte hinzuzufügen oder den Datenverkehr zu einem Gateway Load Balancer in einer anderen Availability Zone zu leiten.

Ja, mehrere Gateway Load Balancer können auf denselben Satz virtueller Appliances verweisen.

Gateway Load Balancer ist ein transparentes Bump-in-the-Wire-Gerät. Es hört alle Arten von IP-Datenverkehr (einschließlich TCP, UDP, ICMP, GRE, ESP und andere) ab. Daher wird auf in einem Gateway Load Balancer nur der IP-Listener erstellt.

Ja. Weitere Informationen erhalten Sie in der Dokumentation zu Beschränkungen für Gateway Load Balancer.

Ja, Sie können die AWS-Managementkonsole, AWS CLI oder API verwenden, um einen Gateway Load Balancer einzurichten.

Ja, Sie können Ihren Gateway Load Balancer in einer einzigen Availability Zone erstellen, indem Sie bei der Erstellung des Load Balancers nur ein Subnetz angeben. Wir empfehlen jedoch, für eine verbesserte Verfügbarkeit mehrere Availability Zones zu verwenden. Sie können für einen Gateway Load Balancer keine Availability Zones hinzufügen oder entfernen, nachdem Sie ihn erstellt haben.

Standardmäßig ist der zonenübergreifende Lastenausgleich deaktiviert. Den Lastausgleich über mehrere Zonen können Sie erst nach der Erstellung Ihres Gateway Load Balancer aktivieren. Hierzu bearbeiten Sie den Abschnitt mit den Lastausgleichsattributen und aktivieren dann das Kontrollkästchen für die Unterstützung der zonenübergreifenden Lastverteilung.

Ja, Ihnen werden für die Datenübertragung zwischen Availability Zones mit Gateway Load Balancer Gebühren berechnet, wenn der zonenübergreifende Lastenausgleich aktiviert ist. Die Gebühren entnehmen Sie bitte dem Abschnitt „Datenübertragung“ auf der Seite mit der Preisübersicht für Amazon-EC2-On-Demand.

Ja. Gateway Load Balancer unterstützt derzeit 300 Ziele pro Availability Zone. Haben Sie Gateway Load Balancer erstellt, können Sie beispielsweise in drei Availability Zones bis zu 900 Ziele registrieren. Beim aktivierten Lastausgleich über mehrere Zonen reduziert sich die Zahl Ihrer Ziele jedoch von 300 Zielen pro Availability Zone auf 300 Ziele pro Gateway Load Balancer.

Sie werden für jede Stunde oder Teilstunde berechnet, in der ein Gateway Load Balancer läuft, sowie für die Anzahl der vom Load Balancer verwendeten Gateway Load Balancer Capacity Units (LCUs) pro Stunde.

Eine LCU ist eine Elastic-Load-Balancing-Metrik, die bestimmt, wie Sie für einen Gateway Load Balancer bezahlen. Eine LCU bestimmt die maximale Ressourcenauslastung in einer der Dimensionen (neue Verbindungen/Datenflüsse, aktive Verbindungen/Datenflüsse und Bandbreite), in welcher der Gateway Load Balancer den Datenverkehr verarbeitet.

Die LCU-Metriken für TCP-Datenverkehr lauten wie folgt:

• 600 neue Abläufe (oder Verbindungen) pro Sekunde.
• 60 000 aktive Abläufe (oder Verbindungen) (pro Minute).
• 1 GB pro Stunde für EC2-Instances, Container und IP-Adressen als Ziele

Nein, es wird Ihnen nur eine der drei Dimensionen in Rechnung gestellt (die mit dem höchsten Wert pro Stunde).

Nein. Mehrere Anforderungen können innerhalb einer einzigen Verbindung gesendet werden.

Sie können die Nutzung aller drei Dimensionen einer LCU über Amazon CloudWatch verfolgen.

Ja.

Um wertvoll zu sein, müssen virtuelle Appliances so wenig zusätzliche Latenzzeit wie möglich einführen, und der Datenverkehr, der zu und von der virtuellen Appliance fließt, muss einer sicheren Verbindung folgen. Gateway Load Balancer-Endpunkte schaffen die sicheren Verbindungen mit geringer Latenz, die zur Erfüllung dieser Anforderungen erforderlich sind.

Mit einem Gateway Load Balancer-Endpunkt können Appliances in verschiedenen AWS-Konten und VPCs untergebracht werden. Dadurch können die Geräte an einem Ort zentralisiert werden, was die Verwaltung erleichtert und den Betriebsaufwand reduziert.

Gateway Load Balancer-Endpunkte sind eine neue Art von VPC-Endpunkten, die die PrivateLink-Technologie verwenden. Da der Netzwerkverkehr von einer Quelle (einem Internet-Gateway, einem VPC usw.) zum Gateway Load Balancer und zurück fließt, gewährleistet ein Gateway Load Balancer Endpunkt die private Konnektivität zwischen den beiden. Der gesamte Datenverkehr fließt über das AWS Netzwerk und die Daten werden niemals dem Internet ausgesetzt, was sowohl die Sicherheit als auch die Leistung erhöht.

Ein Endpunkt der PrivateLink-Schnittstelle wird mit einem Network Load Balancer (NLB) gepaart, um den TCP- und UDP-Verkehr, der für die Web-Anwendungen bestimmt ist, zu verteilen. Im Gegensatz dazu werden Gateway Load Balancer Endpunkte mit Gateway Load Balancer verwendet, um die Quelle und das Ziel des Datenverkehrs zu verbinden. Der Datenverkehr fließt vom Endpunkt des Gateway Load Balancer zum Gateway Load Balancer, durch die virtuellen Appliances und über gesicherte PrivateLink-Verbindungen zurück zum Zielort.

Der Endpunkt von Gateway Load Balancer ist ein VPC-Endpunkt und es gibt keine Begrenzung, wie viele VPC-Endpunkte sich mit einem Service verbinden können, der Gateway Load Balancer verwendet. Wir empfehlen jedoch, nicht mehr als 50 Endpunkte von Gateway Load Balancer mit einem Gateway Load Balancer zu verbinden, um das Risiko einer breiteren Auswirkung im Falle eines Serviceausfalls zu verringern.

Der Classic Load Balancer unterstützt Amazon EC2-Instanzen mit jedem Betriebssystem, das derzeit vom Amazon EC2-Service unterstützt wird.

Der Classic Load Balancer unterstützt die Lastverteilung von Anwendungen mit den Protokollen HTTP, HTTPS (Secure HTTP), SSL (Secure TCP) und TCP.

Sie können für folgende TCP-Ports ein Load Balancing durchführen:

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

Ja. Jeder Classic Load Balancer verfügt über einen zugewiesenen IPv4-, IPv6- und Dualstack-DNS-Namen (sowohl IPv4 und IPv6). IPv6 wird in der VPC nicht unterstützt. Verwenden Sie stattdessen einen Application Load Balancer für eine native Ipv6-Unterstützung in der VPC.

Ja.

Wenn Sie Amazon Virtual Private Cloud verwenden, können Sie für den Front-End des Classic Load Balancers Sicherheitsgruppen konfigurieren.

Ja, Sie können den HTTP-Port 80 und den HTTPS-Port 443 einem einzelnen Classic Load Balancer zuordnen.

Der Classic Load Balancer verfügt über keine Obergrenze für die einzelnen Verbindungen, die mit Ihren lastverteilten Amazon EC2-Instances aufgebaut werden. Sie können davon ausgehen, dass diese Anzahl mit der Anzahl der gleichzeitigen HTTP-, HTTPS- oder SSL-Abfragen oder der Anzahl der gleichzeitigen TCP-Verbindungen, die der Classic Load Balancer empfängt, skaliert wird.

Sie können einen Lastenausgleich für Amazon-EC2-Instances, die über ein gebührenpflichtiges AMI aus AWS Marketplace gestartet wurden, durchführen. Classic Load Balancer unterstützen jedoch keine Instances, die mit einem gebührenpflichtigen AMI von einer Amazon-DevPay-Website gestartet wurden.

Ja. Informationen hierzu finden Sie auf der Webseite zum Elastic Load Balancing.

Ja. Zum Abrufen eines Verlaufs aller Classic Load Balancer-API-Aufrufe, die für Ihr Konto erfolgt sind, aktivieren Sie CloudTrail in der AWS-Managementkonsole.

Ja, Sie können SSL in Classic Load Balancers beenden. Sie müssen ein SSL-Zertifikat auf jedem Classic Load Balancer installieren. Der Classic Load Balancer verwendet dieses Zertifikat, um die Verbindung zu beenden und dann Anforderungen von Clients zu entschlüsseln, bevor sie an die Back-End-Instanzen gesendet werden.

Sie können entweder AWS Certificate Manager verwenden, um ein SSL/TLS-Zertifikat bereitzustellen, oder Sie können das Zertifikat aus anderen Quellen abrufen, indem Sie die Zertifikatsanforderung erstellen, die von der CA signierte Zertifikatsanforderung abrufen und das Zertifikat dann mit dem AWS Identity and Access Management (IAM)-Service hochladen.

Classic Load Balancers sind jetzt in AWS Certificate Manager (ACM) integriert. Durch die Integration in ACM wird das Binden eines Zertifikats an jeden Load Balancer und damit der gesamte SSL-Entladeprozess sehr einfach. Normalerweise ist das Kaufen, Hochladen und Erneuern von SSL/TLS-Zertifikaten ein zeitaufwändiger manueller und komplexer Prozess. Dadurch, dass ACM im Classic Load Balancer integriert ist, wurde dieser gesamte Prozess auf das einfache Anfordern eines vertrauenswürdigen SSL/TLS-Zertifikats und das Auswählen des ACM-Zertifikats für die Bereitstellung mit jedem Load Balancer verkürzt.

Sie können das zonenübergreifende Load Balancing in der Konsole, über die AWS-CLI oder über ein AWS SDK aktivieren. Weitere Einzelheiten finden Sie in der Dokumentation zum zonenübergreifenden Lastenausgleich.

Nein, auch wenn das zonenübergreifende Load Balancing des Classic Load Balancers aktiviert ist, sind regionale Datenübertragungen zwischen Availability Zones gebührenfrei.