Elastic Load Balancing – Häufig gestellte Fragen

F: Welcher Load Balancer eignet sich am besten für meine Anwendung?

A: Elastic Load Balancing (ELB) unterstützt vier Arten von Load Balancern. Sie können den Load Balancer wählen, der am besten zu den Anforderungen Ihrer Anwendung passt. Zum Lastausgleich von HTTP-Anforderungen empfehlen wir Ihnen beispielsweise den Application Load Balancer (ALB). Für den Lastausgleich bei Netzwerk-/Transportprotokollen (Layer 4 – TCP, UDP) oder bei Anwendungen mit extremen Anforderungen an Leistung und geringe Latenz empfehlen wir den Network Load Balancer. Bei Anwendungen, die in das Amazon-Elastic-Compute-Cloud (Amazon EC2)-Classic-Netzwerk eingebettet sind, empfiehlt sich dagegen der Classic Load Balancer. Wenn Sie virtuelle Anwendungen von Drittanbietern ausführen müssen, können Sie den Gateway Load Balancer verwenden.

F: Kann ich über meine Amazon Virtual Private Cloud (VPC) privat auf die Elastic Load Balancing-APIs zugreifen, ohne öffentliche IP-Adressen verwenden zu müssen?

A: Ja, Sie können privat über Ihre Amazon Virtual Private Cloud (VPC) auf die Elastic Load Balancing-APIs zugreifen, indem Sie VPC-Endpunkte erstellen. Mit VPC-Endpunkten wird das Routing zwischen der VPC und den Elastic-Load-Balancing-APIs durch das AWS-Netzwerk gesteuert, ohne dass ein Internet-Gateway, ein NAT-Gateway oder eine Virtual-Private-Network (VPN)-Verbindung erforderlich ist. Die neueste Generation der von Elastic Load Balancing verwendeten VPC-Endpunkte wird von AWS PrivateLink unterstützt. Diese AWS-Technologie ermöglicht die private Konnektivität zwischen AWS-Services, indem Elastic Network-Schnittstellen (ENIs) mit privaten IP-Adressen in Ihren VPCs genutzt werden. Weitere Informationen zu AWS PrivateLink erhalten Sie in der AWS-PrivateLink-Dokumentation.

F: Gibt es ein SLA für Load Balancer?

A: Ja, Elastic Load Balancing garantiert eine monatliche Verfügbarkeit von mindestens 99,99 % für Ihre Load Balancer (Classic, Application oder Network). Um mehr über das SLA zu erfahren und zu erfahren, ob Sie für einen Kredit qualifiziert sind, klicken Sie hier.

F: Auf welchen Betriebssystemen kann ein Application Load Balancer ausgeführt werden?

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

F: Welche Protokolle werden von einem Application Load Balancer unterstützt?

A: Ein Application Load Balancer unterstützt den Lastausgleich für Anwendungen, die die Protokolle HTTP und HTTPS (Secure HTTP) verwenden.

F: Wird HTTP/2 auf einem Application Load Balancer unterstützt?

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

F: Wie kann ich eine statische IP-Adresse oder PrivateLink auf meinem Application Load Balancer verwenden?

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

F: Mit welchen TCP-Ports kann ich eine Lastverteilung durchführen?

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

F: Wird WebSockets auf einem Application Load Balancer unterstützt?

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

F: Wird die Anforderungsnachverfolgung auf einem Application Load Balancer unterstützt?

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

F: Hat ein Classic Load Balancer dieselben Funktionen und Vorteile wie ein Application Load Balancer?

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

F: Kann ich meine Amazon EC2-Instanzen so konfigurieren, dass sie nur Datenverkehr von Application Load Balancers akzeptieren?

A: Ja.

F: Kann ich eine Sicherheitsgruppe für das Front-End eines Application Load Balancers konfigurieren?

A: Ja.

F: Kann ich die bestehenden APIs, die ich mit meinem Classic Load Balancer verwende, auch mit einem Application Load Balancer verwenden?

A: Nein. Application Load Balancer benötigen eine neue Reihe von APIs.

F: Wie kann ich sowohl Application als auch Classic Load Balancers gleichzeitig verwalten? 

A: Mit der ELB Console können Sie Application und Classic Load Balancers über dieselbe 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".

F: Kann ich meinen Classic Load Balancer in einen Application Load Balancer (und umgekehrt) umwandeln?

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

F: Kann ich von einem Classic Load Balancer auf einen Application Load Balancer migrieren?

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

F: Kann ich einen Application Load Balancer als Layer-4-Load Balancer verwenden?

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

F: Kann ich für die Verarbeitung von HTTP- und HTTPS-Anforderungen einen Application Load Balancer verwenden?

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

F: Kann ich zum Zweck der Sicherheitsanalyse und Behebung von Betriebsproblemen einen Verlauf aller Application Load Balancing-API-Aufrufe abrufen, die für mein Konto erfolgt sind?

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

F: Unterstützt ein Application Load Balancer HTTPS-Terminierung?

A: Ja, Sie können eine HTTPS-Verbindung auf dem Application Load Balancer beenden. 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.

F: Was sind die Schritte zum Abrufen eines SSL-Zertifikats?

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

F: Wie kann ein Application Load Balancer in AWS Certificate Manager (ACM) integriert werden?

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

F: Unterstützt ein Application Load Balancer die Back-End-Serverauthentifizierung?

A: Nein, bei einem Application Load Balancer wird im Backend nur die Verschlüsselung unterstützt.

F: Wie aktiviere ich Server Name Indication (SNI) für Application Load Balancer?

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

F: Kann ich einem sicheren Listener mehrere Zertifikate für dieselbe Domain zuweisen?

A: Ja, Sie können einem sicheren Listener mehrere Zertifikate für dieselbe Domäne 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

F: Unterstützt ein Application Load Balancer IPv6?

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

F: Wie legt man Regeln auf einem Application Load Balancer fest?

Sie können für jeden Listener, den Sie für den Load Balancer erstellen, auch eigene Regeln 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.

F: Gibt es Ressourcenbeschränkungen bei einem Application Load Balancer?

A: Ihr AWS-Konto weist diese Beschränkungen für einen Application Load Balancer auf.

F: Wie kann ich meine Webanwendungen hinter einem Load Balancer vor Angriffen aus dem Web schützen?

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

F: Kann ich einen Lastausgleich für eine beliebige IP-Adresse durchführen?

A: 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 lokalen Standorten, die über AWS Direct Connect oder eine VPN-Verbindung erreichbar sind).

F: Wie kann ich einen Lastausgleich für Anwendungen durchführen, die über eine VPC und einen lokalen Standort verteilt sind?

A: 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 Sie 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.

F: Wie kann ich einen Lastausgleich für EC2-Classic-Instanzen durchführen?

A: Ein Lastausgleich für EC2-Classic-Instanzen kann nicht durchgeführt werden, wenn ihre Instance-IDs als Ziele registriert sind. Wenn Sie jedoch diese EC2-Classic Instances über ClassicLink mit der VPC des Load Balancers verknüpfen und die privaten IPs dieser EC2-Classic Instances als Ziel verwenden, dann können Sie den Load Balancer auf die EC2-Classic Instances laden. 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.

F: Wie aktiviere ich die zonenübergreifende Lastverteilung in Application Load Balancer?

A: Das zonenübergreifende Load Balancing ist in Application Load Balancer standardmäßig aktiviert.

F: Wann sollte ich Benutzer anhand der Integration von Application Load Balancer und Amazon Cognito authentifizieren und nicht anhand der nativen Unterstützung von Application Load Balancer für OpenID Connect (IODC) Identitätsanbieter (IdPs)?

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

F: Welche Arten von Umleitungen werden von einem Application Load Balancer unterstützt?

A: Die nachfolgend genannten drei Arten von Umleitungen werden unterstützt.

F: Welche Arten von Inhalten unterstützt Application Load Balancer (ALB) für den Nachrichtentext der Aktion mit feststehender Antwort?

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

F: Wie funktionieren AWS-Lambda-Aufrufe über Application Load Balancer?

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

F: Unterstützen Lambda-Aufrufe mit dem Application Load Balancer Anforderungen über das HTTP- und das HTTPS-Protokoll?

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

F: In welchen AWS-Regionen kann ich Lambda-Funktionen als Ziele mit dem Application Load Balancer verwenden?

A: 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).

F: Ist der Application Load Balancer in lokalen AWS-Zonen verfügbar?

A: Ja, Application Load Balancer ist in der lokalen 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.

F: Wie sieht die Preisgestaltung bei einem Application Load Balancer aus?

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

F: Was ist eine Load Balancer Capacity Unit (LCU)?

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

F: Werde ich auch bei Classic Load Balancers nach LCU abgerechnet?

A: Nein, für Classic Load Balancer werden Ihnen nach wie vor nur die genutzte Bandbreite und ein Stundensatz berechnet.

F: Wie kann ich herausfinden, wie viele LCUs ein Application Load Balancer nutzt?

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

F: Werden mir alle Dimensionen in einer LCU in Rechnung gestellt?

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

F: Werden mir partielle LCUs in Rechnung gestellt?

A: Ja.

F: Gibt es für AWS-Neukunden ein kostenloses Kontingent für einen Application Load Balancer?

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

F: Kann ich für mein kostenloses Kontingent auch eine Kombination aus Application Load Balancer und Classic Load Balancer nutzen?

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

F: Was sind Regelauswertungen?

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

F: Wie funktioniert die LCU-Abrechnung mit unterschiedlichen Zertifikatstypen und Schlüssellängen?

A: 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 Dimension für unterschiedlichen Schlüssellängen für RSA- und ECDSA-Zertifikate auf.

 

F: Werden mir Gebühren für regionale AWS-Datenübertragungen in Rechnung gestellt, wenn ich die zonenübergreifende Lastverteilung in Application Load Balancer aktiviere?

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

F: Wird die Benutzer-Authentifizierung in Application Load Balancer separat in Rechnung gestellt?

A: Nein. Für die Aktivierung der Authentifizierungsfunktion im 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.

F: Wie verrechnen Sie die Application-Load-Balancer-Nutzung mit AWS-Lambda-Zielen?

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

F: Wie ermittle ich die von Lambda-Zielen verarbeiteten Bytes im Vergleich mit den von anderen Zielen verarbeiteten Bytes (Amazon EC2, Container und On-Premises-Server)?

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

F: Kann ich einen TCP- oder UDP-Listener (Layer 4) für meinen Network Load Balancer erstellen?

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

F: Welche sind die Haupteigenschaften des Network Load Balancers?

A: Der Network Load Balancer unterstützt sowohl den Lastausgleich für TCP als auch für UDP (Layer 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.

F: Kann der Network Load Balancer sowohl TCP- als auch UDP-Datenverkehr am gleichen Port verarbeiten?

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

F: Inwiefern unterscheidet sich die Leistung des Network Load Balancer von dem eines TCP-Listener bei einem Classic Load Balancer?

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

F: Kann ich von einem Classic Load Balancer auf einen Network Load Balancer migrieren?

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

F: Gibt es Ressourcenbeschränkungen bei meinem Network Load Balancer?

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

F: Kann ich die AWS-Managementkonsole verwenden, um meinen Network Load Balancer einzurichten?

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

F: Kann ich die bestehende API für Classic Load Balancer für meine Network Balancers verwenden?

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

F: Kann ich meinen Network Load Balancer in einer einzigen Availability Zone erstellen?

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

F: Unterstützt der Network Load Balancer regionale und zonale DNS-Failover?

A: 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 Balancern 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.

F: Kann ich einen Network Load Balancer mit einer Kombination aus IP-Adressen vom ELB und elastischen IP-Adressen oder zugewiesenen privaten IP-Adressen verwenden?

A: Nein. Die Adresse eines Network Load Balancers muss entweder vollständig von Ihnen oder vollständig vom ELB 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.

F: Kann ich meinem Network Load Balancer für jedes Subnetz mehr als eine elastische IP-Adresse zuweisen?

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

F: Was geschieht mit den elastischen IP-Adressen eines Network Load Balancers, wenn ich diesen entferne oder lösche?

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

F: Unterstützt der Network Load Balancer interne Load Balancer?

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

F: Unterstützt der interne Network Load Balancer mehr als eine private IP-Adresse pro Subnetz?

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

F: Kann ich mit meinem Network Load Balancer WebSockets einrichten?

A: Ja, konfigurieren Sie TCP-Listener 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.

F: Kann ich einen Lastausgleich für eine beliebige IP-Adresse durchführen?

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

F: Kann ich den Network Load Balancer zur Einrichtung von AWS PrivateLink verwenden?

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

F: Was ist ein UDP-Datenfluss?

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

F: Welches Leerlauf-Zeitlimit unterstützt der Network Load Balancer?

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

F: Welcher Vorteil ergibt sich, wenn ich auf Container hinter einem Load Balancer mit IP-Adressen anstelle von Instance-IDs verweise?

A: Jeder Container auf einer Instance kann jetzt eine eigene Sicherheitsgruppe haben 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. Da der gleiche Port für mehrere Container verwendet werden kann, können Container auf einer Instanz über bekannte anstatt über zufällige Ports miteinander kommunizieren.

F: Wie kann ich einen Lastausgleich für Anwendungen durchführen, die über eine VPC und einen lokalen Standort verteilt sind?

A: 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 Sie 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.

F: Wie kann ich einen Lastausgleich für EC2-Classic-Instanzen durchführen?

A: Ein Lastausgleich für EC2-Classic-Instanzen kann nicht durchgeführt werden, wenn ihre Instance-IDs als Ziele registriert sind. Wenn Sie jedoch diese EC2-Classic Instances über ClassicLink mit der VPC des Load Balancers verknüpfen und die privaten IPs dieser EC2-Classic Instances als Ziel verwenden, dann können Sie den Load Balancer auf die EC2-Classic Instances laden. 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.

F: Wie aktiviere ich die zonenübergreifende Lastverteilung in Network Load Balancer?

A: Sie können den zonenübergreifenden Lastausgleich erst nach der Erstellung Ihres Network Load Balancers 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.

F: Werden mir Gebühren für regionale AWS-Datenübertragungen in Rechnung gestellt, wenn ich die zonenübergreifende Lastverteilung in Network Load Balancer aktiviere?

A: Ja. Bei Verwendung des Network Load Balancers fallen für regionale Datenübertragungen zwischen Availability Zones Gebühren an, wenn das zonenübergreifende Load Balancing 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.

F: Wirkt sich die zonenübergreifende Lastverteilung auf die Grenzwerte des Network Load Balancer aus?

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

F: Unterstützt Network Load Balancer die TLS-Terminierung?

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

F: Wird die Quell-IP beim Beenden von TLS auf Network Load Balancer beibehalten?

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

F: Was sind die Schritte zum Abrufen eines SSL-Zertifikats?

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

F: Wie aktiviere ich Server Name Indication (SNI) für meinen Network Load Balancer?

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

F: Wie integriert sich der Network Load Balancer in den AWS Certificate Manager (ACM) oder Identity Access Manager (IAM)?

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

F: Unterstützt Network Load Balancer die Backend-Server-Authentifizierung?

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

F: Welche Zertifikatstypen werden von Network Load Balancer unterstützt?

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

F: In welchen AWS-Regionen wird TLS-Terminierung auf Network Load Balancer unterstützt?

A: 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).

F: Wie sieht die Preisgestaltung bei einem Network Load Balancer aus?

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

F: Was ist eine Load Balancer Capacity Unit (LCU)?

A: 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 welcher der Network Load Balancer den Datenverkehr verarbeitet.

F: Was sind die LCU-Metriken für TCP-Datenverkehr beim Network Load Balancer?

A: 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

A: 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
  

F: Was sind die LCU-Metriken für TLS-Datenverkehr auf Network Load Balancer?

A: 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

F: Sind neue Verbindungen/Datenflüsse pro Sekunde dasselbe wie Anforderungen pro Sekunde?

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

F: Werde ich auch bei Classic Load Balancers nach LCU abgerechnet?

A: Nein. Für Classic Load Balancer werden Ihnen nach wie vor nur die genutzte Bandbreite und ein Stundensatz berechnet.

F: Wie kann ich herausfinden, wie viele LCUs ein Network Load Balancer nutzt?

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

F: Werden mir alle Dimensionen in einer LCU in Rechnung gestellt?

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

F: Werden mir partielle LCUs in Rechnung gestellt?

A: Ja.

F: Gibt es für AWS-Neukunden ein kostenloses Kontingent für einen Network Load Balancer?

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

F: Kann ich für mein kostenloses Kontingent auch eine Kombination aus Network Load Balancer, Application Load Balancer und Classic Load Balancer nutzen?

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

F: Wann sollte ich Gateway Load Balancer verwenden, im Gegensatz zu Network Load Balancer oder Application Load Balancer?

A: 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 Funktionsvergleich.

F: Wird Gateway Load Balancer pro Region oder pro Availability Zone (AZ) bereitgestellt?

Gateway Load Balancer läuft innerhalb einer AZ.

F: Welche sind die Haupteigenschaften des Gateway Load Balancers?

A: 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. Siehe Gateway-Load-Balancer-Funktionen in dieser Tabelle. 

F: Führt Gateway Load Balancer die TLS-Terminierung durch?

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.

F: Hält Gateway Load Balancer den Zustand der Anwendung aufrecht?

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

F: Wie definiert Gateway Load Balancer einen Ablauf?

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

F: Wann sollte ich 5-Tupel-, 3-Tupel- und 2-Tuple-Stickiness auf Gateway Load Balancer verwenden?

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.

F: Welches Leerlauf-Timeout unterstützt der Gateway Load Balancer?

A: Das Leerlauf-Zeitlimit des Gateway Load Balancer 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.

F: Können Anwendungen die Pakete fragmentieren?

A: Nein. Zielanwendungen vom Gateway Load Balancer (GWLB) sollten keine Pakete fragmentieren, die sie beim zurücksenden an den GWLB erhalten haben. Die von der Anwendung erstellten Fragmente werden beim Gateway Load Balancer ausgesondert, da der Ebene-4-Header in den IP-Fragmenten nicht vorhanden ist. Um zu verhindern, dass in der Anwendung Fragmentierung stattfindet, empfehlen wir, auf Ihrer Anwendung Jumbo-Frame zu aktivieren, oder die Netzwerkschnittstelle der Anwendung so einzustellen, dass sie die maximale erwünschte MTU nutzt. Dadurch wird eine transparente Weiterleitung erreicht, da der Originalinhalt des Pakets unverändert beibehalten wird.

F: Wie geht Gateway Load Balancer mit dem Fehler einer virtuellen Anwendungs-Instance in einer einzigen Availability Zone um?

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.

F: Wie geht Gateway Load Balancer mit dem Ausfall aller virtuellen Appliances innerhalb einer einzigen AZ um?

Wenn alle virtuellen Appliances innerhalb und der Availability Zone ausfallen, lässt Gateway Load Balancer den Netzwerkverkehr ausfallen. 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.

F: Kann ich ein Gerät Appliance so konfigurieren, dass sie ein Ziel für mehr als einen Gateway Load Balancer ist?

Ja, mehrere Gateway Load Balancer können auf denselben Satz virtueller Geräte verweisen.

F: Welche Art von Listener kann ich für meinen Gateway Load Balancer erstellen?

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

F: Gibt es Ressourcenbeschränkungen bei meinem Gateway Load Balancer?

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

F: Kann ich die AWS-Managementkonsole verwenden, um meinen Gateway Load Balancer einzurichten?

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

F: Kann ich meinen Gateway Load Balancer in einer einzigen Availability Zone erstellen?

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

F: Wie aktiviere ich den Lastausgleich über mehrere Zonen in Gateway Load Balancer?

A: Standardmäßig ist der Lastausgleich über mehrere Zonen 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 des Lastausgleichs über mehrere Zonen.

F: Werden mir Gebühren für AWS-Datenübertragungen in Rechnung gestellt, wenn ich den Lastausgleich über mehrere Zonen in Gateway Load Balancer aktiviere?

A: Ja. Bei Verwendung des Gateway Load Balancers fallen für Datenübertragungen zwischen Availability Zones Gebühren an, wenn der Lastausgleich über mehrere Zonen 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.

F: Wirkt sich der Lastausgleich über mehrere Zonen auf die Grenzwerte des Gateway Load Balancer aus?

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

F: Wie sieht die Preisgestaltung bei einem Gateway Load Balancer aus?

A: 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 (LCU) pro Stunde.

F: Was ist eine Load Balancer Capacity Unit (LCU)?

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

F: Was sind die LCU-Metriken auf Gateway Load Balancer?

A: Die LCU-Kennzahlen 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

F: Warum brauche ich einen Gateway Load Balancer-Endpunkt?

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.

F: Wie helfen Gateway-Load-Balancer-Endpunkte bei der Zentralisierung?

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.

F: Wie funktionieren Gateway-Load-Balancer-Endpunkte?

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.

F: Inwiefern unterscheiden sich die Endpunkte der PrivateLink-Schnittstelle von den Gateway Load Balancer-Endpunkten?

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.

F: Wie viele Endpunkte von Gateway Load Balancer kann ich mit einem Gateway Load Balancer verbinden?

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.

F: Auf welchen Betriebssystemen kann ein Classic Load Balancer ausgeführt werden?

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

F: Welche Protokolle werden von einem Classic Load Balancer unterstützt?

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

F: Für welche TCP-Ports kann ich Load Balancing durchführen?

A: Sie können für folgende TCP-Ports einen Lastausgleich durchführen:

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

F: Unterstützt der Classic Load Balancer IPv6-Datenverkehr?

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

F: Kann ich meine Amazon EC2-Instances so konfigurieren, dass nur vom Classic Load Balancer Datenverkehr akzeptiert wird?

A: Ja.

F: Kann ich eine Sicherheitsgruppe für das Front-End des Classic Load Balancers konfigurieren?

A: Wenn Sie Amazon Virtual Private Cloud verwenden, können Sie für das Frontend des Classic Load Balancers Sicherheitsgruppen konfigurieren.

F: Kann ich für die Verarbeitung von HTTP- und HTTPS-Anforderungen einen Classic Load Balancer verwenden?

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

F: Wie viele Verbindungen müssen meine lastverteilten Amazon EC2-Instances vom Classic Load Balancer akzeptieren?

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

F: Kann ich Load Balancing bei Amazon EC2-Instances durchführen, die über ein gebührenpflichtiges AMI gestartet wurden?

A: Sie können Load Balancing bei Amazon EC2-Instances durchführen, die über ein gebührenpflichtiges AMI aus AWS Marketplace gestartet wurden. Der Classic Load Balancer unterstützt jedoch keine Instances, die mit einem gebührenpflichtigen AMI von einer Amazon DevPay-Website gestartet wurden.

F: Kann ich Classic Load Balancer in Amazon Virtual Private Cloud nutzen?

A: Ja. Informationen hierzu finden Sie auf der Elastic Load Balancing-Webseite.

F: Kann ich zum Zweck der Sicherheitsanalyse und Behebung von Betriebsproblemen einen Verlauf aller Classic Load Balancer-API-Aufrufe abrufen, die für mein Konto erfolgt sind?

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

F: Unterstützen Classic Load Balancers die SSL-Terminierung?

A: Ja, Sie können SSL in Classic Load Balancern 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.

F: Was sind die Schritte zum Abrufen eines SSL-Zertifikats?

A: 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 mit dem AWS Identity and Access Management (IAM)-Service hochladen.

F: Wie kann ein Classic Load Balancer in AWS Certificate Manager (ACM) integriert werden?

A: Classic Load Balancer 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.

F: Wie aktiviere ich die zonenübergreifende Lastverteilung in Classic Load Balancer?

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

F: Werden mir Gebühren für regionale AWS-Datenübertragungen in Rechnung gestellt, wenn ich die zonenübergreifende Lastverteilung in Classic Load Balancer aktiviere?

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