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.
Sie können JavaScript Code mit Node.js in AWS Lambda ausführen. Lambda bietet Laufzeiten für Node.js, die Ihren Code ausführen, um Ereignisse zu verarbeiten. Ihr Code wird in einer Umgebung ausgeführt, die die Rolle AWS SDK for JavaScript, with credentials from a AWS Identity and Access Management (IAM) enthält, die Sie verwalten. Weitere Informationen zu den SDK-Versionen, die in den Laufzeiten von Node.js enthalten sind, finden Sie unter SDK-Versionen, die zur Laufzeit enthalten sind.
Lambda unterstützt die folgenden Node.js-Laufzeiten.
Name | ID | Betriebssystem | Datum der Veraltung | Blockfunktion erstellen | Blockfunktion aktualisieren |
---|---|---|---|---|---|
Node.js 22 |
|
Amazon Linux 2023 |
30. April 2027 |
1. Juni 2027 |
1. Juli 2027 |
Node.js 20 |
|
Amazon Linux 2023 |
30. April 2026 |
1. Juni 2026 |
1. Juli 2026 |
Node.js 18 |
|
Amazon Linux 2 |
1. Sept. 2025 |
1. Oktober 2025 |
1. November 2025 |
Erstellen einer Funktion Node.js.
-
Öffnen Sie die Lambda-Konsole
. -
Wählen Sie Funktion erstellen aus.
-
Konfigurieren Sie die folgenden Einstellungen:
-
Funktionsname: Geben Sie einen Namen für die Funktion ein.
-
Laufzeit: Wählen Sie Node.js 22.x aus.
-
-
Wählen Sie Funktion erstellen aus.
Die Konsole erstellt eine Lambda-Funktion mit einer einzigen Quelldatei mit dem Namen index.mjs
. Mit dem integrierten Code-Editor können Sie diese Datei bearbeiten und weitere Dateien hinzufügen. Wählen Sie im Abschnitt BEREITSTELLEN die Option Bereitstellen aus, um den Code Ihrer Funktion zu aktualisieren. Um Ihren Code auszuführen, wählen Sie anschließend im Abschnitt TESTEREIGNISSE die Option Testereignis erstellen aus.
Die index.mjs
-Datei exportiert eine Funktion mit dem Namen handler
, die ein Ereignisobjekt und ein Kontext-Objekt übernimmt. Dies ist die Handler-Funktion, die bei einem Aufruf der Funktion von Lambda aufgerufen wird. Die Node.js-Funktionslaufzeit ruft Aufrufereignisse von Lambda ab und leitet sie an den Handler weiter. In der Konfiguration der Funktion lautet der Wert für den Handler index.handler
.
Wenn Sie Ihren Funktionscode speichern, erstellt die Lambda-Konsole ein Bereitstellungspaket für das ZIP-Dateiarchiv. Wenn Sie Ihren Funktionscode außerhalb der Konsole (mit einer IDE) entwickeln, müssen Sie ein Bereitstellungspaket erstellen, um Ihren Code in die Lambda-Funktion hochzuladen.
Die Funktionslaufzeit übergibt neben dem Aufrufereignis ein Context-Objekt an den Handler. Das Context-Objekt enthält zusätzliche Informationen zum Aufruf, zur Funktion und zur Ausführungsumgebung. Weitere Informationen erhalten Sie über die Umgebungsvariablen.
Ihre Lambda-Funktion wird mit einer CloudWatch Logs-Protokollgruppe geliefert. Die Funktionslaufzeit sendet Details zu jedem Aufruf an CloudWatch Logs. Es leitet alle Protokolle weiter, die Ihre Funktion während des Aufrufs ausgibt. Wenn Ihre Funktion einen Fehler zurückgibt, formatiert Lambda den Fehler und gibt ihn an den Aufrufer zurück.
Themen
Initialisierung von Node.js
Node.js verfügt über ein eindeutiges Ereignisschleifenmodell, das bewirkt, dass sich das Initialisierungsverhalten von anderen Laufzeiten unterscheidet. Insbesondere verwendet Node.js ein nicht blockierendes I/O-Modell, das asynchrone Operationen unterstützt. Dieses Modell ermöglicht es Node.js, für die meisten Workloads effizient zu arbeiten. Wenn beispielsweise eine Node.js-Funktion einen Netzwerkaufruf durchführt, kann diese Anforderung als asynchrone Operation bezeichnet und in eine Callback-Warteschlange gestellt werden. Die Funktion verarbeitet möglicherweise andere Vorgänge innerhalb des Hauptaufruf-Batches, ohne blockiert zu werden, indem sie darauf wartet, dass der Netzwerkaufruf zurückgegeben wird. Sobald der Netzwerkaufruf abgeschlossen ist, wird sein Rückruf ausgeführt und dann aus der Rückrufwarteschlange entfernt.
Einige Initialisierungsaufgaben werden möglicherweise asynchron ausgeführt. Diese asynchronen Aufgaben garantieren nicht, dass sie die Ausführung vor einem Aufruf abschließen. Beispielsweise ist Code, der einen Netzwerkaufruf zum Abrufen eines Parameters aus dem AWS Parameterspeicher durchführt, möglicherweise nicht vollständig, wenn Lambda die Handler-Funktion ausführt. Infolgedessen kann die Variable während eines Aufrufs null sein. Um dies zu vermeiden, stellen Sie sicher, dass Variablen und anderer asynchroner Code vollständig initialisiert sind, bevor Sie mit der restlichen Kerngeschäftslogik der Funktion fortfahren.
Alternativ können Sie Ihren Funktionscode als ES-Modul bezeichnen, sodass Sie await
auf der obersten Ebene der Datei außerhalb des Bereichs Ihres Funktionshandlers verwenden können. Wenn Sie await
jedes Promise
verwenden, wird der asynchrone Initialisierungscode vor den Handler-Aufrufen abgeschlossen, wodurch die Wirksamkeit der bereitgestellten Gleichzeitigkeit bei der Reduzierung der Kaltstart-Latenz maximiert wird. Weitere Informationen und ein Beispiel finden Sie unter Verwenden von Node.js-ES-Modulen und Erwarten auf oberster Ebene in AWS Lambda
Designieren eines Funktionshandlers als ES-Modul
Standardmäßig behandelt Lambda Dateien mit dem .js
-Suffix als CommonJS-Module. Optional können Sie Ihren Code als ES-Modul festlegen. Sie können dies auf zwei Arten tun: durch Angabe von type
als module
in der package.json
-Datei der Funktion oder durch Verwendung der Dateinamenerweiterung .mjs
. Im ersten Ansatz behandelt Ihr Funktionscode alle .js
-Dateien als ES-Module, während im zweiten Szenario nur die Datei, die Sie mit .mjs
angeben, ein ES-Modul ist. Sie können ES-Module und CommonJS-Module mischen, indem Sie sie als .mjs
bzw. .cjs
benennen, da .mjs
-Dateien immer ES-Module sind und .cjs
-Dateien immer CommonJS-Module sind.
Lambda beim Laden von ES-Modulen Ordner in der NODE_PATH
-Umgebungsvariable. Sie können das AWS SDK, das in der Runtime enthalten ist, mithilfe von ES-Modulanweisungen laden. import
Sie können ES-Module auch aus Ebenen laden.
SDK-Versionen, die zur Laufzeit enthalten sind
Die Version des AWS SDK, die in der Runtime von Node.js enthalten ist, hängt von der Laufzeitversion und Ihrer ab AWS-Region. Um die Version des SDK zu finden, die in der von Ihnen verwendeten Laufzeit enthalten ist, erstellen Sie eine Lambda-Funktion mit dem folgenden Code.
Beispiel index.mjs
import packageJson from '@aws-sdk/client-s3/package.json' with { type: 'json' };
export const handler = async () => ({ version: packageJson.version });
Dies gibt eine Antwort im folgenden Format zurück:
{
"version": "3.632.0"
}
Verwenden von Keepalive für TCP-Verbindungen
Der standardmäßige Node.js-HTTP/HTTPS-Agent erstellt eine neue TCP-Verbindung für jede neue Anforderung. Um die Kosten für den Aufbau neuer Verbindungen zu vermeiden, ist Keep-alive in nodejs18.x
und späteren Lambda-Laufzeiten standardmäßig aktiviert. Keepalive kann die Anforderungszeiten für Lambda-Funktionen reduzieren, die mehrere API-Aufrufe unter Verwendung des SDK ausführen.
Informationen zum Deaktivieren von Keep-Alive finden Sie unter Wiederverwenden von Verbindungen mit Keep-Alive in Node.js im AWS SDK for 3.x Developer Guide. JavaScript Weitere Informationen zur Verwendung von Keep-Alive finden Sie im Developer Tools Blog unter HTTP keep-alive is default on in modular
CA-Zertifikat wird geladen
Für Node.js-Laufzeitversionen bis Node.js 18 lädt Lambda automatisch Amazon-spezifische CA-Zertifikate (Certificate Authority, Zertifizierungsstelle), um Ihnen die Erstellung von Funktionen zu erleichtern, die mit anderen AWS-Services interagieren. Lambda enthält beispielsweise die Amazon-RDS-Zertifikate, die für die Validierung des in Ihrer Amazon-RDS-Datenbank installierten Server-Identitätszertifikats erforderlich sind. Dieses Verhalten kann sich bei Kaltstarts auf die Leistung auswirken.
Ab Node.js 20 lädt Lambda standardmäßig keine zusätzlichen CA-Zertifikate mehr. Die Laufzeit Node.js 20 enthält eine Zertifikatsdatei mit allen Amazon-CA-Zertifikaten, die sich unter /var/runtime/ca-cert.pem
befinden. Um dasselbe Verhalten aus Node.js 18 und früheren Laufzeiten wiederherzustellen, setzen Sie die Umgebungsvariable NODE_EXTRA_CA_CERTS
auf /var/runtime/ca-cert.pem
.
Für eine optimale Leistung empfehlen wir, nur die benötigten Zertifikate mit Ihrem Bereitstellungspaket zu bündeln und diese über die Umgebungsvariable NODE_EXTRA_CA_CERTS
zu laden. Die Zertifikatsdatei sollte aus einem oder mehreren vertrauenswürdigen Stammzertifikaten oder Zertifikaten von Zwischenzertifizierungsstellen im PEM-Format bestehen. Fügen Sie für RDS die erforderlichen Zertifikate beispielsweise zusammen mit Ihrem Code als certificates/rds.pem
hinzu. Laden Sie dann die Zertifikate, indem Sie NODE_EXTRA_CA_CERTS
auf /var/task/certificates/rds.pem
festlegen.