Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Netzwerk
Sie konfigurieren den Netzwerkzugriff für Ihre AWS Lambda microVMs, indem Sie Ihrer microVM zur Laufzeit Network Connector-Ressourcen zuordnen. Netzwerkanschlüsse werden beim Aufrufen angegeben run-microvm und können nicht geändert werden, während eine MicroVM läuft.
-Übersicht
Jede MicroVM kann über unabhängige Netzwerkkonfigurationen für den Eingang (eingehend) und den Ausgang (ausgehend) verfügen:
-
Eingangsnetzwerkanschlüsse ermöglichen eingehende Konnektivität. Clients stellen eine Verbindung zu einem vom Service verwalteten HTTPS-Endpunkt her, und Lambda leitet den Datenverkehr an Ports weiter, die Sie in der MicroVM konfigurieren. Ingress-Connectors werden AWS verwaltet — Sie referenzieren sie per ARN, wenn Sie eine MicroVM ausführen.
-
Ausgehende Netzwerkanschlüsse ermöglichen ausgehenden Datenverkehr. Standardmäßig haben MicroVMs öffentlichen Internetzugang. Sie können stattdessen einen vom Kunden verwalteten VPC-Ausgangsconnector erstellen, um ausgehenden Datenverkehr über Ihre VPC weiterzuleiten.
Ein einziger Connector kann für viele MicroVMs wiederverwendet werden — dies ist das beabsichtigte Verwendungsmuster.
Eingehende Konnektivität
Jede Lambda MicroVM ist über eine eindeutige HTTPS-Endpunkt-URL erreichbar, die Ihnen bei einem Anruf zugewiesen wird. run-microvm Clients senden Anfragen über HTTPS an diesen Endpunkt. Lambda leitet jede Anfrage an einen Port in Ihrer MicroVM weiter, wo Ihre Anwendung sie empfängt.
Standardmäßig werden am Endpunkt empfangene Anfragen an Port 8080 innerhalb der MicroVM weitergeleitet. Informationen zur Weiterleitung an einen anderen Port finden Sie unter. Port-Routing
Die folgenden Protokolle werden auf dem Eingangsendpunkt unterstützt:
-
HTTP/1.1
-
HTTP/2
-
WebSockets
-
gRPC
-
Server-Sent Ereignisse (SSE)
Anmerkung
Der Datenverkehr zwischen Ihrem Client und dem MicroVM-Endpunkt wird immer mit TLS verschlüsselt. Ihre Anwendung kann Anfragen intern entweder über HTTP oder HTTPS bearbeiten.
Port-Routing
Lambda wählt den Zielport in Ihrer MicroVM in der folgenden Prioritätsreihenfolge aus:
-
X-aws-proxy-portHeader — Fügen Sie bei Standard-HTTP-Anfragen diesen Header mit der Zielportnummer hinzu. -
WebSocket Unterprotokoll — Wenn Ihr WebSocket Client keine benutzerdefinierten Header einrichten kann, geben Sie den Zielport als Unterprotokoll mit dem Namen an
lambda-microvms.port., wobei die PortnummerNNsteht. Sie geben Unterprotokolle an, wenn Sie die Verbindung öffnen. WebSocket Ein Beispiel finden Sie unter Protokolle. -
Standard (8080) — Wenn keines von beiden angegeben ist, wird die Route zu Port 8080 angefordert.
Wichtig
Der Zielport muss innerhalb des im allowedPorts Authentifizierungstoken definierten Ports liegen. Anfragen an nicht autorisierte Ports erhalten die Antwort 403 Forbidden.
Authentifizierung
Alle Anfragen an einen MicroVM-Endpunkt erfordern ein gültiges Authentifizierungstoken im X-aws-proxy-auth Header. Sie generieren Token mitcreate-microvm-auth-token. Jedes Token ist eine verschlüsselte JWE-Zeichenfolge (JSON Web Encryption) mit folgendem Gültigkeitsbereich:
-
Eine bestimmte MicroVM (identifiziert durch ID).
-
Eine Reihe zulässiger Ports (einzelner Port, Bereich oder alle Ports).
-
Eine Ablaufzeit (konfiguriert bei der Token-Erstellung).
Das folgende Beispiel erstellt ein Token und verwendet es, um eine authentifizierte Anfrage zu senden:
aws lambda-microvms create-microvm-auth-token \ --microvm-identifiermicrovm-id\ --expiration-in-minutes 30 \ --allowed-ports '[{"port":8080}]'
curl 'https://microvm-endpoint' \ -H 'X-aws-proxy-auth:TOKEN' \ -H 'X-aws-proxy-port: 8080'
Eine vollständige Anleitung zum Erstellen von Token und zum Herstellen einer Verbindung zu einer MicroVM, einschließlich WebSocket Verbindungen, finden Sie unter. Verbindung zu einer MicroVM herstellen
Fehlermeldungen
Die folgenden HTTP-Statuscodes werden vom MicroVM-Endpunkt zurückgegeben, wenn er eine Anfrage nicht verarbeiten oder an Ihre Anwendung senden kann. Diese Antworten kommen vom Endpunkt, nicht von Ihrer Anwendung.
| Code | Status | Ursache und Lösung |
|---|---|---|
| 400 | Inkorrekte Anfrage | Fehlerhafte Anfrage oder ein ungültiger Port-Header oder ein ungültiges WebSocket Unterprotokoll. Überprüfen Sie das Format. |
| 403 | Forbidden | Fehlendes, abgelaufenes oder ungültiges Token oder der angeforderte Port ist nicht im Token enthaltenallowedPorts. Generieren Sie ein neues Token oder verwenden Sie einen zulässigen Port. |
| 429 | Zu viele Anfragen | Das Ratenlimit wurde überschritten (auf Kontoebene oder pro microVM). Versuchen Sie es erneut mit exponentiellem Backoff. |
| 500 | Internal Server Error | Es ist ein interner Fehler aufgetreten. Wiederholen Sie die Anforderung. |
| 502 | Bad Gateway | Die Anwendung reagiert nicht oder die automatische Wiederaufnahme war innerhalb der maximalen Anzahl von Wiederholungsversuchen nicht erfolgreich. Siehe Auto-resume. |
Anfordern von Headern
Der X-aws-proxy-* Header-Namespace wird von Lambda für Anforderungsmetadaten wie das Authentifizierungstoken (X-aws-proxy-auth) und den Zielport (X-aws-proxy-port) reserviert. Lambda entfernt X-aws-proxy-* Header, bevor die Anfrage an Ihre Anwendung weitergeleitet wird.
Request/response Bandbreite
Jede Lambda MicroVM hat eine request/response Bandbreite, die linear mit ihrer Größe skaliert. Diese Bandbreite gilt für den gesamten Datenverkehr über den MicroVM-Endpunkt, sowohl für eingehende Anfragen als auch für ausgehende Antworten.
| Größe der MicroVM (Basiswert) | Max. Bandbreite |
|---|---|
| 0,5 GB, 0,25 vCPU | 1 MB/s (8 Mbit/s) |
| 1 GB, 0,5 vCPU | 2 MB/s (16 Mbit/s) |
| 2 GB, 1 vCPU | 4 MB/s (32 Mbit/s) |
| 4 GB, 2 vCPU | 8 MB/s (64 Mbit/s) |
| 8 GB, 4 vCPU | 16 MB/s (128 Mbit/s) |
Wenn Sie aufgrund der Netzwerksättigung eine erhöhte Latenz bei Anfragen feststellen, reduzieren Sie entweder die Parallelität Ihrer Anfragen oder die Größe der Nutzlast, oder wählen Sie eine größere MicroVM-Größe, um die verfügbare Bandbreite zu erhöhen.
HTTP/2 Unterstützung
Lambda MicroVMS unterstützt HTTP/2 am eingehenden Endpunkt. Lambda handelt das Protokoll während des TLS-Handshakes über ALPN (Application-Layer Protocol Negotiation) aus, wobei es bevorzugt HTTP/2 wird und darauf zurückgreift. HTTP/1.1 Ein HTTP/2-capable Client verwendet es automatisch.
So verwenden Sie es HTTP/2 zwischen dem Endpunkt und Ihrer Anwendung innerhalb der MicroVM:
-
Ihre Anwendung verwendet TLS — Lambda verhandelt HTTP/2 mit Ihrer Anwendung über ALPN und greift darauf zurück, HTTP/1.1 falls dies HTTP/2 nicht unterstützt wird.
-
Ihre Anwendung verwendet HTTP im Klartext-Format — Fügen Sie den
X-aws-proxy-force-h2: trueHeader in Ihre Anfrage ein, der für die Verbindung zu Ihrer Anwendung verwendet HTTP/2 werden soll.
Ausgehende Konnektivität
Standardmäßig haben Lambda MicroVMs öffentlichen Internetzugang auf dem Ausgangspfad. Um MicroVMs mit Ressourcen in Ihren privaten VPCs — wie RDS ElastiCache, internen APIs und lokalen Systemen über Direct Connect oder VPN — zu verbinden, erstellen Sie einen Lambda Network Connector mit Ihrer VPC-Konfiguration.
Wenn Sie VPC-Egress verwenden, unterliegt ausgehender Datenverkehr Sicherheitsgruppenregeln und Netzwerk-ACLs, die den Verkehr in Ihrer VPC regeln.
Arbeiten mit ausgehenden Netzwerkverbindern
Ausgangsnetzwerkanschlüsse leiten ausgehenden Datenverkehr von Ihrer MicroVM über Ihre VPC weiter. Sie erstellen einmal einen Connector und verweisen dann per ARN darauf, wenn Sie MicroVMS über den run-microvm Befehl starten.
Voraussetzungen
Bevor Sie einen Netzwerkconnector erstellen, benötigen Sie eine IAM-Rolle, die es Lambda ermöglicht, Elastic Network Interfaces (ENIs) in Ihrer VPC zu erstellen. Die Rolle erfordert die folgenden Berechtigungen:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CreateENI", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": [ "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ] }, { "Sid": "TagENI", "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:network-interface/*", "Condition": { "StringEquals": { "ec2:ManagedResourceOperator": "network-connectors.lambda.amazonaws.com" } } } ] }
Einen Netzwerkkonnektor erstellen
Erstellen Sie einen Connector, indem Sie Ihre VPC-Subnetze, Sicherheitsgruppen und Ihr Netzwerkprotokoll angeben (IPv4oderDualStack):
aws lambda-core create-network-connector \ --name my-connector \ --configuration '{ "VpcEgressConfiguration": { "SubnetIds": ["subnet-xxx"], "SecurityGroupIds": ["sg-xxx"], "NetworkProtocol": "IPv4", "AssociatedComputeResourceTypes": ["MicroVm"] } }' \ --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole
Status des Netzwerkkonnektors
Ein Connector muss sich im ACTIVE Status befinden, bevor Sie ihn referenzieren könnenrun-microvm.
| Status | Description |
|---|---|
PENDING |
Der Connector wird erstellt (die zugrunde liegenden ENIs werden bereitgestellt). |
ACTIVE |
Der Connector ist einsatzbereit. |
INACTIVE |
Der Connector ist vorübergehend inaktiv. |
FAILED |
Die Bereitstellung oder Aktualisierung ist fehlgeschlagen. Überprüfen Sie StateReason. |
DELETING |
Der Connector wird gelöscht; ENIs werden bereinigt. |
DELETE_FAILED |
Der Löschvorgang ist fehlgeschlagen. |
Ausführen einer MicroVM mit einem Netzwerkanschluss
Verweisen Sie auf den Connector-ARN, wenn Sie eine MicroVM ausführen:
aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \ --egress-network-connectorsconnector-arn\ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800,"autoResumeEnabled":false}'
Anmerkung
Bevor Sie einen Connector aktualisieren oder löschen, stellen Sie sicher, dass alle MicroVMs, die ihn verwenden, beendet wurden. Das Ändern eines Connectors, der aktiv verwendet wird, kann zu Netzwerkverbindungsproblemen beim Ausführen von MicroVMs führen.