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. # Beheben von Problemen in Lambda Die folgenden Themen enthalten Ratschläge zur Fehlerbehebung bei Fehlern und Problemen, die bei der Verwendung der Lambda-API, -Konsole oder -Tools auftreten können. Wenn Sie auf ein Problem stoßen, das hier nicht aufgeführt ist, können Sie die Schaltfläche **Feedback** auf dieser Seite verwenden, um es zu melden. Weitere Tipps zur Fehlerbehebung und Antworten auf häufig gestellte Supportfragen finden Sie im [AWS- Wissenscenter](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Weitere Informationen zum Debuggen und zur Problembehandlung für Lambda-Anwendungen finden Sie bei Serverless Land unter [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops). **Topics** + [Beheben von Konfigurationsproblemen in Lambda](troubleshooting-configuration.md) + [Beheben von Bereitstellungsproblemen in Lambda](troubleshooting-deployment.md) + [Beheben von Aufruf-Problemen in Lambda](troubleshooting-invocation.md) + [Beheben von Ausführungsproblemen in Lambda](troubleshooting-execution.md) + [Behebung von Problemen mit der Zuordnung von Ereignisquellen in Lambda](troubleshooting-event-source-mapping.md) + [Beheben von Netzwerkproblemen in Lambda](troubleshooting-networking.md) # Beheben von Konfigurationsproblemen in Lambda Ihre Funktionskonfigurationseinstellungen können sich auf die Gesamtleistung und das Verhalten Ihrer Lambda-Funktion auswirken. Diese verursachen möglicherweise keine tatsächlichen Funktionsfehler, können jedoch zu unerwarteten Timeouts und Ergebnissen führen. Die folgenden Themen enthalten Tipps zur Fehlerbehebung für häufig auftretende Probleme im Zusammenhang mit den Konfigurationseinstellungen von Lambda-Funktionen. **Topics** + [Arbeitsspeicherkonfigurationen](#memory-config) + [CPU-gebundene Konfigurationen](#cpu-bound-config) + [Zeitüberschreitungen](#timeouts) + [Speicherlecks zwischen Aufrufen](#memory-leakage) + [Asynchrone Ergebnisse wurden bei einem späteren Aufruf zurückgegeben](#asynchronous-results) ## Arbeitsspeicherkonfigurationen Sie können eine Lambda-Funktion so konfigurieren, dass sie zwischen 128 MB und 10 240 MB Speicher verwendet. Standardmäßig wird jeder in der Konsole erstellten Funktion die kleinste Speichermenge zugewiesen. Viele Lambda-Funktionen sind bei dieser niedrigsten Einstellung leistungsfähig. Wenn Sie jedoch große Codebibliotheken importieren oder speicherintensive Aufgaben ausführen, reichen 128 MB nicht aus. Wenn Ihre Funktionen viel langsamer als erwartet ausgeführt werden, besteht der erste Schritt darin, die Speichereinstellung zu erhöhen. So können Sie die Funktion Ihres Handlers nutzen, um die Leistung Ihrer Funktion zu verbessern. ## CPU-gebundene Konfigurationen Bei rechenintensiven Vorgängen kann es vorkommen, dass Ihre Funktion eine geringere Leistung als erwartet aufweist. Dies kann daran liegen, dass Ihre Funktion CPU-gebunden ist. In diesem Fall kann die Berechnungskapazität der Funktion nicht mit der Arbeit Schritt halten. Mit Lambda können Sie die CPU-Konfiguration zwar nicht direkt ändern, die CPU wird jedoch indirekt über die Speichereinstellungen gesteuert. Der Lambda-Dienst weist proportional mehr virtuelle CPU zu, wenn Sie mehr Arbeitsspeicher zuweisen. Bei 1,8 GB Arbeitsspeicher wird einer Lambda-Funktion eine ganze vCPU zugewiesen und oberhalb dieser Grenze hat sie Zugriff auf mehr als einen vCPU-Kern. Mit 10 240 MB hat sie 6 vCPUs zur Verfügung. Mit anderen Worten: Sie können die Leistung verbessern, indem Sie die Speicherzuweisung erhöhen, auch wenn die Funktion nicht den gesamten Speicher nutzt. ## Zeitüberschreitungen [Timeouts](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) für Lambda-Funktionen können zwischen 1 und 900 Sekunden (15 Minuten) eingestellt werden. Standardmäßig ist dieser Wert in der Lambda-Konsole auf 3 Sekunden eingestellt. Der Timeout-Wert ist eine Sicherheitsvorrichtung, die sicherstellt, dass Funktionen nicht unbegrenzt ausgeführt werden. Nachdem der Timeout-Wert erreicht ist, stoppt Lambda den Funktionsaufruf. Wenn ein Timeout-Wert nahe der durchschnittlichen Dauer einer Funktion festgelegt wird, erhöht sich das Risiko, dass die Funktion unerwartet abbricht. Die Dauer einer Funktion kann je nach Umfang der Datenübertragung und -verarbeitung sowie der Latenz aller Dienste, mit denen die Funktion interagiert, variieren. Häufige Ursachen für Timeouts: + Beim Herunterladen von Daten aus S3-Buckets oder anderen Datenspeichern ist der Download größer oder dauert länger als im Durchschnitt. + Eine Funktion sendet eine Anfrage an einen anderen Service, dessen Beantwortung länger dauert. + Die einer Funktion zur Verfügung gestellten Parameter erfordern eine höhere Rechenkomplexität in der Funktion, wodurch der Aufruf länger dauert. Stellen Sie beim Testen Ihrer Anwendung sicher, dass Ihre Tests die Größe und Menge der Daten sowie realistische Parameterwerte genau wiedergeben. Wichtig ist, dass Sie Datensätze verwenden, die an der Obergrenze dessen liegen, was für Ihren Workload vernünftigerweise zu erwarten ist. Implementieren Sie zusätzlich Obergrenzen für Ihren Workload, wo immer dies möglich ist. In diesem Beispiel könnte die Anwendung für jeden Dateityp eine maximale Größenbeschränkung verwenden. Anschließend können Sie die Leistung Ihrer Anwendung für eine Reihe erwarteter Dateigrößen bis einschließlich der Höchstgrenzen testen. ## Speicherlecks zwischen Aufrufen Globale Variablen und Objekte, die in der INIT-Phase eines Lambda-Aufrufs gespeichert sind, behalten ihren Status zwischen warmen Aufrufen bei. Sie werden erst vollständig zurückgesetzt, wenn die Ausführungsumgebung zum ersten Mal ausgeführt wird (auch als „Kaltstart“ bezeichnet). Alle im Handler gespeicherten Variablen werden zerstört, wenn der Handler beendet wird. Die INIT-Phase wird am besten zum Einrichten von Datenbankverbindungen, Laden von Bibliotheken, Erstellen von Caches und Laden unveränderlicher Assets verwendet. Wenn Sie Bibliotheken von Drittanbietern für mehrere Aufrufe in derselben Ausführungsumgebung verwenden, sollten Sie deren Dokumentation zur Verwendung in einer Serverless-Computerumgebung überprüfen. Einige Bibliotheken für Datenbankverbindungen und Protokollierung speichern möglicherweise Zwischenaufrufergebnisse und andere Daten. Dies führt dazu, dass der Speicherverbrauch dieser Bibliotheken mit nachfolgenden Warmaufrufen zunimmt. In diesem Fall kann es vorkommen, dass die Lambda-Funktion nicht über genügend Speicher verfügt, selbst wenn Ihr benutzerdefinierter Code Variablen korrekt entsorgt. Dieses Problem betrifft Aufrufe, die in warmen Ausführungsumgebungen auftreten. Der folgende Code erzeugt beispielsweise ein Speicherleck zwischen Aufrufen. Die Lambda-Funktion verbraucht bei jedem Aufruf zusätzlichen Speicher, indem sie die Größe eines globalen Arrays erhöht: ``` let a = [] exports.handler = async (event) => { a.push(Array(100000).fill(1)) } ``` Bei einer Konfiguration mit 128 MB Speicher zeigt die Registerkarte **Überwachung** der Lambda-Funktion nach 1 000 Aufrufen dieser Funktion die typischen Änderungen bei Aufrufen, Dauer und Fehleranzahl, wenn ein Speicherleck auftritt: ![\[Debugging-Operationen, Abbildung 4\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-4.png) 1. **Aufrufe**: Eine gleichmäßige Transaktionsrate wird periodisch unterbrochen, da die Aufrufe länger dauern, bis sie abgeschlossen sind. Im eingeschwungenen Zustand verbraucht das Speicherleck nicht den gesamten der Funktion zugewiesenen Speicher. Wenn die Leistung abnimmt, paginiert das Betriebssystem den lokalen Speicher, um den wachsenden Speicherbedarf der Funktion zu decken, was dazu führt, dass weniger Transaktionen abgeschlossen werden. 1. **Dauer**: Bevor der Funktion der Speicherplatz ausgeht, beendet sie Aufrufe mit einer konstanten zweistelligen Millisekundenrate. Wenn ein Paging stattfindet, verlängert sich die Dauer um eine Größenordnung. 1. **Anzahl der Fehler**: Wenn der Speicherverlust den zugewiesenen Speicher übersteigt, kommt es schließlich zu einem Funktionsfehler, weil die Berechnung den Timeout überschreitet, oder die Ausführungsumgebung stoppt die Funktion. Nach dem Fehler startet Lambda die Ausführungsumgebung neu, was erklärt, warum alle drei Diagramme eine Rückkehr zum ursprünglichen Zustand zeigen. Wenn Sie die CloudWatch-Metriken für die Dauer erweitern, erhalten Sie mehr Details zu den Statistiken für die minimale, maximale und durchschnittliche Dauer: ![\[Debugging-Operationen, Abbildung 5\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-5.png) Um die Fehler zu finden, die bei den 1 000 Aufrufen erzeugt wurden, können Sie die Abfragesprache CloudWatch Insights verwenden. Die folgende Abfrage schließt Informationsprotokolle aus, um nur die Fehler zu melden: ``` fields @timestamp, @message | sort @timestamp desc | filter @message not like 'EXTENSION' | filter @message not like 'Lambda Insights' | filter @message not like 'INFO'  | filter @message not like 'REPORT' | filter @message not like 'END' | filter @message not like 'START' ``` Ein Abgleich mit der Protokollgruppe für diese Funktion zeigt, dass Zeitüberschreitungen für die periodischen Fehler verantwortlich waren: ![\[Debugging-Operationen, Abbildung 6\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-6.png) ## Asynchrone Ergebnisse wurden bei einem späteren Aufruf zurückgegeben Bei Funktionscode, der asynchrone Muster verwendet, ist es möglich, dass die Callback-Ergebnisse eines Aufrufs in einem zukünftigen Aufruf zurückgegeben werden. In diesem Beispiel wird Node.js verwendet, aber dieselbe Logik kann auch auf andere Laufzeiten angewendet werden, die asynchrone Muster verwenden. Die Funktion verwendet die traditionelle Callback-Syntax in JavaScript. Sie ruft eine asynchrone Funktion mit einem inkrementellen Zähler auf, der die Anzahl der Aufrufe verfolgt: ``` let seqId = 0 exports.handler = async (event, context) => { console.log(`Starting: sequence Id=${++seqId}`) doWork(seqId, function(id) { console.log(`Work done: sequence Id=${id}`) }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` Wenn sie mehrmals hintereinander aufgerufen werden, treten die Ergebnisse der Callbacks bei nachfolgenden Aufrufen auf: ![\[Debugging-Operationen, Abbildung 7\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-7.png) 1. Der Code ruft die `doWork`-Funktion auf und stellt als letzten Parameter eine Callback-Funktion bereit. 1. Es dauert einige Zeit, bis die `doWork`-Funktion abgeschlossen ist, bevor der Callback aufgerufen wird. 1. Die Protokollierung der Funktion zeigt an, dass der Aufruf beendet wird, bevor die Ausführung der `doWork`-Funktion abgeschlossen ist. Darüber hinaus werden nach dem Start einer Iteration Callbacks aus früheren Iterationen verarbeitet, wie in den Protokollen gezeigt. In JavaScript werden asynchrone Callbacks mit einer [Event-Schleife](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) behandelt. Andere Laufzeiten verwenden andere Mechanismen zur Behandlung der Gleichzeitigkeit. Wenn die Ausführungsumgebung der Funktion endet, friert Lambda die Umgebung bis zum nächsten Aufruf ein. Nach der Wiederaufnahme setzt JavaScript die Verarbeitung der Ereignisschleife fort, die in diesem Fall einen asynchronen Rückruf von einem früheren Aufruf enthält. Ohne diesen Kontext kann es den Anschein haben, dass die Funktion ohne Grund Code ausführt und beliebige Daten zurückgibt. Sie ist vielmehr ein Artefakt der Interaktion zwischen der Gleichzeitigkeit zur Laufzeit und den Ausführungsumgebungen. Dadurch besteht die Möglichkeit, dass private Daten aus einem früheren Aufruf in einem späteren Aufruf erscheinen. Es gibt zwei Möglichkeiten, die Funktion Ihres Handlers aufzuweisen. Erstens bietet JavaScript die [Schlüsselwörter async und await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function), um die asynchrone Entwicklung zu vereinfachen und die Codeausführung zu erzwingen, bis ein asynchroner Aufruf abgeschlossen ist. Die obige Funktion kann mit diesem Ansatz wie folgt umgeschrieben werden: ``` let seqId = 0 exports.handler = async (event) => { console.log(`Starting: sequence Id=${++seqId}`) const result = await doWork(seqId) console.log(`Work done: sequence Id=${result}`) } function doWork(id) { return new Promise(resolve => { setTimeout(() => resolve(id), 4000) }) } ``` Die Verwendung dieser Syntax verhindert, dass der Handler beendet wird, bevor die asynchrone Funktion beendet ist. Wenn in diesem Fall der Callback länger dauert als das Timeout der Lambda-Funktion, gibt die Funktion einen Fehler aus, anstatt das Callback-Ergebnis bei einem späteren Aufruf zurückzugeben: ![\[Debugging-Operationen, Abbildung 8\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-8.png) 1. Der Code ruft die asynchrone `doWork`-Funktion unter Verwendung des Schlüsselworts „await“ im Handler auf. 1. Die Funktion `doWork` benötigt eine gewisse Zeit, bevor sie das Versprechen auflöst. 1. Bei der Funktion kommt es zu einem Timeout, da `doWork` länger dauert, als der Timeout erlaubt, und das Ergebnis des Rückrufs bei einem späteren Aufruf nicht zurückgegeben wird. Im Allgemeinen sollten Sie sicherstellen, dass alle Hintergrundprozesse oder Rückrufe im Code abgeschlossen sind, bevor der Code beendet wird. Wenn dies in Ihrem Anwendungsfall nicht möglich ist, können Sie einen Bezeichner verwenden, um sicherzustellen, dass der Rückruf zum aktuellen Aufruf gehört. Dazu können Sie die vom Kontextobjekt bereitgestellte *awsRequestId* verwenden. Indem Sie diesen Wert an den asynchronen Callback übergeben, können Sie den übergebenen Wert mit dem aktuellen Wert vergleichen, um festzustellen, ob der Callback von einem anderen Aufruf stammt: ``` let currentContext exports.handler = async (event, context) => { console.log(`Starting: request id=$\{context.awsRequestId}`) currentContext = context doWork(context.awsRequestId, function(id) { if (id != currentContext.awsRequestId) { console.info(`This callback is from another invocation.`) } }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` ![\[Debugging-Operationen, Abbildung 9\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-9.png) 1. Der Lambda-Funktionshandler verwendet den Kontextparameter, der Zugriff auf eine eindeutige Aufrufanforderungs-ID ermöglicht. 1. Die `awsRequestId` wird an die doWork-Funktion übergeben. Im Callback wird die ID mit der `awsRequestId` des aktuellen Aufrufs verglichen. Wenn diese Werte unterschiedlich sind, kann der Code entsprechende Maßnahmen ergreifen. # Beheben von Bereitstellungsproblemen in Lambda Wenn Sie Ihre Funktion aktualisieren, stellt Lambda die Änderung durch Starten der neuen Instances der Funktion mit aktualisiertem Code oder aktualisierten Einstellungen bereit. Bereitstellungsfehler verhindern die Verwendung der neuen Version und können auf Probleme mit Bereitstellungspaket, Code, Berechtigungen oder Tools zurückzuführen sein. Wenn Sie Updates für Ihre Funktion direkt mit der Lambda-API oder mit einem Client wie dem bereitstellen AWS CLI, können Sie Fehler von Lambda direkt in der Ausgabe sehen. Wenn Sie Dienste wie AWS CloudFormation, oder verwenden AWS CodeDeploy AWS CodePipeline, suchen Sie in den Protokollen oder im Eventstream für diesen Dienst nach der Antwort von Lambda. Die folgenden Themen enthalten Ratschläge zur Fehlerbehebung bei Fehlern und Problemen, die bei der Verwendung der Lambda-API, -Konsole oder -Tools auftreten können. Wenn Sie auf ein Problem stoßen, das hier nicht aufgeführt ist, können Sie die Schaltfläche **Feedback** auf dieser Seite verwenden, um es zu melden. Weitere Tipps zur Fehlerbehebung und Antworten auf häufig gestellte Supportfragen finden Sie im [AWS - Wissenscenter](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Weitere Informationen zum Debuggen und zur Problembehandlung für Lambda-Anwendungen finden Sie bei Serverless Land unter [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops). **Topics** + [Allgemein: Berechtigung wird verweigert/Kann solche Datei nicht laden](#troubleshooting-deployment-denied) + [Allgemein: Beim Aufrufen von UpdateFunctionCode](#troubleshooting-deployment-updatefunctioncode) + [Amazon S3: Fehlercode PermanentRedirect.](#troubleshooting-deployment-PermanentRedirect) + [Allgemein: Kann nicht gefunden werden, kann nicht geladen werden, Klasse nicht gefunden, keine solche Datei oder kein Verzeichnis](#troubleshooting-deployment-functionHandler1) + [Allgemein: Undefinierter Methodenhandler](#troubleshooting-deployment-functionHandler2) + [Allgemein: Speicherlimit für Lambda-Code überschritten](#troubleshooting-deployment-CodeStorageExceeded) + [Lambda: Ebenenkonvertierung ist fehlgeschlagen.](#troubleshooting-deployment-LayerConversionFailed) + [Lambda: oder InvalidParameterValueException RequestEntityTooLargeException](#troubleshooting-deployment-InvalidParameterValueException1) + [Lambda: InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2) + [Lambda: Kontingente für Gleichzeitigkeit und Speicher](#troubleshooting-deployment-quotas) + [Lambda: Ungültige Aliaskonfiguration für bereitgestellte Gleichzeitigkeit](#troubleshooting-deployment-provisioned-concurrency) ## Allgemein: Berechtigung wird verweigert/Kann solche Datei nicht laden **Fehler:** *EACCES: Zugriff verweigert, öffnen Sie '/ .js' var/task/index* **Fehler:** *kann eine derartige Datei nicht laden – Funktion* **Fehler:** *[Errno 13*] Zugriff verweigert: '/ .py' var/task/function Die Lambda-Laufzeit benötigt die Berechtigung zum Lesen der Dateien in Ihrem Bereitstellungspaket. In der oktalen Schreibweise von Linux-Berechtigungen benötigt Lambda 644 Berechtigungen für nicht ausführbare Dateien (rw-r--r--) und 755 Berechtigungen () für Verzeichnisse und ausführbare Dateien. rwxr-xr-x Verwenden Sie unter Linux und MacOS den `chmod`-Befehl, um Dateiberechtigungen für Dateien und Verzeichnisse in Ihrem Bereitstellungspaket zu ändern. Um beispielsweise einer nicht ausführbaren Datei die richtigen Berechtigungen zu geben, führen Sie den folgenden Befehl aus. ``` chmod 644 ``` Informationen zum Ändern von Dateiberechtigungen in Windows finden Sie unter [Festlegen, Anzeigen, Ändern oder Entfernen von Berechtigungen für ein Objekt](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) in der Microsoft-Windows-Dokumentation. **Anmerkung** Wenn Sie Lambda nicht die Berechtigungen gewähren, die es für den Zugriff auf Verzeichnisse in Ihrem Bereitstellungspaket benötigt, setzt Lambda die Berechtigungen für diese Verzeichnisse auf 755 (). rwxr-xr-x ## Allgemein: Beim Aufrufen von UpdateFunctionCode **Fehler:** *Beim Aufrufen der UpdateFunctionCode Operation ist ein Fehler aufgetreten (RequestEntityTooLargeException)* Wenn Sie ein Bereitstellungspaket oder ein Ebenenarchiv direkt in Lambda hochladen, ist die Größe der ZIP-Datei auf 50 MB begrenzt. Um eine größere Datei hochzuladen, speichern Sie sie in Amazon S3 und verwenden Sie die S3Bucket- und S3Key--Parameter. **Anmerkung** Wenn Sie eine Datei direkt mit dem AWS CLI AWS SDK oder auf andere Weise hochladen, wird die binäre ZIP-Datei in ein Base64-Format konvertiert, wodurch sich ihre Größe um etwa 30% erhöht. Um dies und die Größe anderer Parameter in der Anforderung zu ermöglichen, ist die tatsächliche von Lambda angewendete Größenbeschränkung der Anforderung größer. Aus diesem Grund ist der Grenzwert von 50 MB ein ungefährer Wert. ## Amazon S3: Fehlercode PermanentRedirect. **Fehler:** *Während ist ein Fehler aufgetreten GetObject. S3-Fehlercode: PermanentRedirect. S3-Fehlermeldung: Der Bucket befindet sich in dieser Region: us-east-2. Verwenden Sie diese Region, um die Anfrage zu wiederholen* Wenn Sie das Bereitstellungspaket einer Funktion aus einem Amazon-S3-Bucket hochladen, muss sich der Bucket in derselben Region wie die Funktion befinden. Dieses Problem kann auftreten, wenn Sie ein Amazon S3 S3-Objekt in einem Aufruf angeben oder die Befehle package und deploy in der AWS CLI oder AWS SAM CLI verwenden. [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) Erstellen Sie einen Bucket mit Bereitstellungsartefakt für jede Region, in der Sie Anwendungen entwickeln. ## Allgemein: Kann nicht gefunden werden, kann nicht geladen werden, Klasse nicht gefunden, keine solche Datei oder kein Verzeichnis **Fehler:** *Modul 'function' kann nicht gefunden werden* **Fehler:** *kann eine derartige Datei nicht laden – Funktion* **Fehler:** *Modul 'function' kann nicht importiert werden* **Fehler:** *Klasse nicht gefunden: function.Handler* **Fehlerfork/exec /var/task/function:** *Keine solche Datei oder kein solches Verzeichnis* **Fehler:** *Der Typ 'Function.Handler' kann nicht aus der Assembly 'Function' geladen werden.*' Der Name der Datei oder Klasse in der Handler-Konfiguration Ihrer Funktion stimmt nicht mit Ihrem Code überein. Weitere Informationen finden Sie im folgenden Abschnitt . ## Allgemein: Undefinierter Methodenhandler **Fehler:** *index.handler ist nicht definiert oder wurde nicht exportiert* **Fehler:** *Handler 'handler' fehlt für Modul 'function'* **Fehler:** *undefinierte Methode `Handler'* für \$1<:0x000055b76ccebf98> LambdaHandler **Fehler:** *Keine öffentliche Methode namens handleRequest mit der entsprechenden Methodensignatur für Klasse function.Handler gefunden* **Fehler:** *Die Methode 'handleRequest' konnte nicht im Typ 'Function.Handler' der Assembly 'Function' gefunden werden* Der Name der Handler-Methode in der Handler-Konfiguration Ihrer Funktion stimmt nicht mit Ihrem Code überein. Jede Laufzeit definiert eine Namenskonvention für Handler, wie z. *filename* *methodname*. Der Handler ist die Methode im Code Ihrer Funktion, die von der Laufzeit ausführt wird, wenn Ihre Funktion aufgerufen wird. Lambda stellt für einige Sprachen eine Bibliothek mit einer Schnittstelle bereit, die erwartet, dass eine Handler-Methode einen bestimmten Namen hat. Weitere Informationen zur Handlerbenennung für jede Sprache finden Sie in den folgenden Themen. + [Erstellen von Lambda-Funktionen mit Node.js](lambda-nodejs.md) + [Erstellen von Lambda-Funktionen mit Python](lambda-python.md) + [Erstellen von Lambda-Funktionen mit Ruby](lambda-ruby.md) + [Erstellen von Lambda-Funktionen mit Java](lambda-java.md) + [Erstellen von Lambda-Funktionen mit Go](lambda-golang.md) + [Erstellen von Lambda-Funktionen mit C\$1](lambda-csharp.md) + [Aufbau von Lambda-Funktionen mit PowerShell](lambda-powershell.md) ## Allgemein: Speicherlimit für Lambda-Code überschritten **Fehler:** *Das Code-Speicherlimit wurde überschritten.* Lambda speichert Ihren Funktionscode in einem internen S3-Bucket, der nur für Ihr Konto bestimmt ist. Jedem AWS Konto werden 75 GB Speicherplatz in jeder Region zugewiesen. Der Codespeicher umfasst den gesamten Speicherplatz, der sowohl von Lambda-Funktionen als auch von Lambda-Ebenen verwendet wird. Wenn Sie das Kontingent erreichen, erhalten Sie eine, *CodeStorageExceededException*wenn Sie versuchen, neue Funktionen bereitzustellen. Verwalten Sie den verfügbaren Speicherplatz, indem Sie alte Versionen von Funktionen bereinigen, ungenutzten Code entfernen oder Lambda-Ebenen verwenden. Darüber hinaus empfiehlt es sich, [separate AWS Konten für separate Workloads zu verwenden](concepts-application-design.md#multiple-accounts), um die Verwaltung der Speicherkontingente zu erleichtern. Sie können Ihre gesamte Speichernutzung in der Lambda-Konsole im Untermenü **Dashboard** einsehen: ![\[Überwachung der Beobachtbarkeit Abbildung 26\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-observability-figure-26.png) ## Lambda: Ebenenkonvertierung ist fehlgeschlagen. **Fehler:** *Lambda-Ebenenkonvertierung ist fehlgeschlagen. Hinweise zur Lösung dieses Problems finden Sie auf der Seite „Beheben von Bereitstellungsproblemen in Lambda“ im Lambda-Benutzerhandbuch.* Wenn Sie eine Lambda-Funktion mit einer Ebene konfigurieren, führt Lambda die Ebene mit Ihrem Funktionscode zusammen. Wenn dieser Prozess nicht abgeschlossen wird, gibt Lambda diesen Fehler zurück. Führen Sie in diesem Fall die folgenden Schritte aus: + Löschen Sie alle ungenutzten Dateien von Ihrer Ebene. + Löschen Sie alle symbolischen Links in Ihrer Ebene. + Benennen Sie alle Dateien um, die denselben Namen wie ein Verzeichnis in einer der Ebenen Ihrer Funktion haben. ## Lambda: oder InvalidParameterValueException RequestEntityTooLargeException **FehlerInvalidParameterValueException:** *Lambda konnte Ihre Umgebungsvariablen nicht konfigurieren, da die von Ihnen angegebenen Umgebungsvariablen das Limit von 4 KB überschritten haben. Gemessene Zeichenfolge: \$1"A1":" u SFe Y5 7ATNx5BSM... cyPiPn* **Fehler:RequestEntityTooLargeException:** *Die Anfrage muss für den Vorgang kleiner als 5120 Byte sein UpdateFunctionConfiguration * Die maximale Größe des Variablenobjekts, das in der Konfiguration der Funktion gespeichert ist, darf 4096 Bytes nicht überschreiten. Dazu gehören Schlüsselnamen, Werte, Anführungszeichen, Kommas und Klammern. Die Gesamtgröße des HTTP-Anforderungstexts ist ebenfalls begrenzt. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Runtime": "nodejs24.x", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Environment": { "Variables": { "BUCKET": "amzn-s3-demo-bucket", "KEY": "file.txt" } }, ... } ``` In diesem Beispiel umfasst das Objekt 39 Zeichen und benötigt 39 Bytes, wenn es als Zeichenfolge gespeichert wird (ohne Leerzeichen `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}`. Standard-ASCII-Zeichen in Umgebungsvariablenwerten verwenden jeweils ein Byte. Erweiterte ASCII- und Unicode-Zeichen können zwischen 2 und 4 Bytes pro Zeichen verwenden. ## Lambda: InvalidParameterValueException **FehlerInvalidParameterValueException:** *Lambda konnte Ihre Umgebungsvariablen nicht konfigurieren, da die von Ihnen angegebenen Umgebungsvariablen reservierte Schlüssel enthalten, deren Änderung derzeit nicht unterstützt wird*. Lambda reserviert einige Umgebungsvariablenschlüssel zur internen Verwendung. Beispielsweise wird `AWS_REGION` von der Laufzeit verwendet, um die aktuelle Region zu bestimmen, und kann nicht außer Kraft gesetzt werden. Andere Variablen, wie z. B. `PATH`, werden von der Laufzeit verwendet, können aber in Ihrer Funktionskonfiguration erweitert werden. Eine vollständige Liste finden Sie unter [Definierte Laufzeitumgebungsvariablen](configuration-envvars.md#configuration-envvars-runtime). ## Lambda: Kontingente für Gleichzeitigkeit und Speicher **Fehler:** Die * ConcurrentExecutions für die Funktion angegebene Funktion senkt den Wert des Kontos UnreservedConcurrentExecution unter den Mindestwert* **Fehler:** *Der Wert MemorySize '' hat die Einschränkung nicht erfüllt: Das Element muss einen Wert haben, der kleiner oder gleich 3008* ist Diese Fehler treten auf, wenn Sie für Ihr Konto die [Kontingente](gettingstarted-limits.md) für Gleichzeitigkeit oder Speicher überschreiten. Bei neuen AWS Konten wurden Parallelität und Speicherkontingente reduziert. Um Fehler im Zusammenhang mit der Gleichzeitigkeit zu beheben, können Sie [eine Kontingenterhöhung beantragen](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). Sie können keine Erhöhung des Speicherkontingents beantragen. + **Parallelität:** Ein Fehler kann auftreten, wenn Sie wenn Sie versuchen, eine Funktion mit reservierter oder bereitgestellter Parallelität zu erstellen, oder wenn Ihre funktionsspezifische Parallelitätsanforderung ([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)) das Parallelitätskontingent Ihres Kontos übersteigt. + **Speicher:** Fehler treten auf, wenn die der Funktion zugewiesene Speichermenge das Speicherkontingent Ihres Kontos übersteigt. ## Lambda: Ungültige Aliaskonfiguration für bereitgestellte Gleichzeitigkeit **Fehler:*** Ungültige Aliaskonfiguration für bereitgestellte Gleichzeitigkeit* Dieser Fehler tritt auf, wenn Sie versuchen, den Code oder die Konfiguration einer Lambda-Funktion zu aktualisieren, während ein Alias mit bereitgestellter Gleichzeitigkeit auf eine Version verweist, bei der Probleme auftreten. Lambda initialisiert Ausführungsumgebungen für die bereitgestellte Gleichzeitigkeit vorab. Wenn diese Umgebungen aufgrund von Codefehlern, Ressourcenbeschränkungen oder einem betroffenen Stack und Alias nicht ordnungsgemäß initialisiert werden können, schlägt die Bereitstellung fehl. Führen Sie in diesem Fall die folgenden Schritte aus: 1. **Den Alias rückgängig machen:** Aktualisieren Sie den Alias vorübergehend, sodass er auf die zuvor funktionierende Version verweist. ``` aws lambda update-alias \ --function-name \ --name \ --function-version ``` 1. **Lambda-Initialisierungscode korrigieren:** Stellen Sie sicher, dass der Initialisierungscode, der außerhalb des Handlers ausgeführt wird, keine nicht abgefangenen Ausnahmen enthält, und initialisieren Sie die Clients und Verbindungen. 1. **Sicherheit erneut bereitstellen:** Stellen Sie korrigierten Code bereit und veröffentlichen Sie eine neue Version. Aktualisieren Sie dann den Alias so, dass er auf die korrigierte Version verweist. Aktivieren Sie optional die [bereitgestellte Gleichzeitigkeit](provisioned-concurrency.md) erneut, falls erforderlich. Falls Sie dies verwenden AWS CloudFormation, aktualisieren Sie die Stack-Definition, `FunctionVersion:!GetAtt version.Version` sodass der Alias auf die funktionierende Version verweist: ``` alias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref function FunctionVersion: !GetAtt version.Version Name: BLUE ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 1 ``` # Beheben von Aufruf-Problemen in Lambda Wenn Sie eine Lambda-Funktion aufrufen, validiert Lambda die Anforderung und überprüft die Skalierungskapazität, bevor es das Ereignis an Ihre Funktion oder bei asynchronem Aufruf an die Ereigniswarteschlange sendet. Aufruffehler können durch Probleme mit Anforderungsparametern, Ereignisstruktur, Funktionseinstellungen, Benutzerberechtigungen, Ressourcenberechtigungen oder Grenzwerten verursacht werden. Wenn Sie Ihre Funktion direkt aufrufen, sehen Sie Aufruffehler in der Antwort von Lambda. Wenn Sie Ihre Funktion asynchron mit einer Ereignisquellen-Zuweisung oder über einen anderen Service aufrufen, finden Sie möglicherweise Fehler in Protokollen, eine Warteschlange für unzustellbare Nachrichten oder ein Ziel für fehlerhafte Ereignisse. Die Optionen für die Fehlerbehandlung und das Wiederholungsverhalten variieren je nachdem, wie Sie Ihre Funktion aufrufen, und nach der Art des Fehlers. Eine Liste der Fehlertypen, die der `Invoke`-Vorgang zurückgeben kann, finden Sie unter [Aufrufen](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). **Topics** + [Lambda: Funktion bricht während der Init-Phase ab (Sandbox.Timedout)](#troubleshooting-timeouts) + [IAM: Lambda: InvokeFunction nicht autorisiert](#troubleshooting-invocation-noauth) + [Lambda: Es konnte kein gültiger Bootstrap gefunden werden (Runtime). InvalidEntrypoint)](#troubleshooting-invocation-bootstrap) + [Lambda: Vorgang kann nicht ausgeführt werden ResourceConflictException](#troubleshooting-invocation-ResourceConflictException) + [Lambda: Funktion bleibt im Status Pending](#troubleshooting-invocation-pending) + [Lambda: Eine Funktion verwendet alle Parallelität](#troubleshooting-invocation-allconcurrency) + [Allgemein: Funktion kann nicht mit anderen Konten oder Diensten aufgerufen werden](#troubleshooting-invocation-cannotinvoke) + [Allgemein: Funktionsaufruf bleibt im Looping](#troubleshooting-invocation-loop) + [Lambda: Alias-Routing mit bereitgestellter Parallelität](#troubleshooting-invocation-alias) + [Lambda: Kaltstarts mit bereitgestellter Parallelität](#troubleshooting-invocation-coldstart) + [Lambda: Kaltstarts mit neuen Versionen](#troubleshooting-invocation-newversion) + [Lambda: Unerwartetes Beenden von Node.js während der Laufzeit (Runtime). NodejsExit)](#troubleshooting-invocation-nodejs-exit) + [EFS: Die Funktion konnte das EFS-Dateisystem nicht mounten](#troubleshooting-invocation-efsmount) + [EFS: Die Funktion konnte keine Verbindung zum EFS-Dateisystem herstellen](#troubleshooting-invocation-efsconnect) + [EFS: Die Funktion konnte das EFS-Dateisystem aufgrund eines Timeouts nicht mounten](#troubleshooting-invocation-efstimeout) + [S3-Dateien: Die Funktion konnte das S3-Dateisystem nicht mounten](#troubleshooting-invocation-s3filesmount) + [S3-Dateien: Die Funktion konnte keine Verbindung zum S3-Dateisystem herstellen](#troubleshooting-invocation-s3filesconnect) + [S3-Dateien: Die Funktion konnte das S3-Dateisystem aufgrund eines Timeouts nicht mounten](#troubleshooting-invocation-s3filestimeout) + [Lambda: Lambda hat einen IO-Prozess erkannt, der zu lange dauerte](#troubleshooting-invocation-ioprocess) + [Container: Fehler CodeArtifactUserException](#troubleshooting-deployment-container-artifact) + [Container: InvalidEntrypoint Fehler](#troubleshooting-deployment-container-entrypoint) ## Lambda: Funktion bricht während der Init-Phase ab (Sandbox.Timedout) **Fehler:** *Zeitüberschreitung der Aufgabe nach 3,00 Sekunden* Wenn die [Init](lambda-runtime-environment.md#runtimes-lifecycle-ib)-Phase abläuft, initialisiert Lambda die Ausführungsumgebung erneut, indem es die `Init`-Phase erneut durchläuft, wenn die nächste Aufrufanforderung eintrifft. Dies wird als [unterdrückte Initialisierung](lambda-runtime-environment.md#suppressed-init) bezeichnet. Wenn Ihre Funktion jedoch mit einer kurzen [Timeout-Dauer](configuration-timeout.md) (in der Regel etwa 3 Sekunden) konfiguriert ist, kann es sein, dass die unterdrückte Initialisierung während der zugewiesenen Timeout-Dauer nicht abgeschlossen wird, sodass für die `Init`-Phase erneut ein Timeout auftritt. Alternativ wird die unterdrückte Initialisierung abgeschlossen, es bleibt aber nicht genügend Zeit für den Abschluss der [Invoke](lambda-runtime-environment.md#runtimes-lifecycle-invoke)-Phase übrig, was zu einem Timeout für die `Invoke`-Phase führt. Um Timeout-Fehler zu reduzieren, verwenden Sie eine oder mehrere der folgenden Strategien: + **Erhöhen Sie die Dauer des Funktions-Timeouts**: Verlängern Sie das [Timeout](configuration-timeout.md), um den `Init`- und `Invoke`-Phasen Zeit zu geben, erfolgreich abgeschlossen zu werden. + **Erhöhen Sie die Zuweisung des Funktionsspeichers**: Mehr [Arbeitsspeicher](configuration-memory.md) bedeutet auch eine proportionalere CPU-Zuweisung, wodurch sowohl die `Init`-Phase als auch die `Invoke`-Phasen beschleunigt werden können. + **Optimieren Sie den Code für die Funktionsinitialisierung**: Reduzieren Sie die für die Initialisierung benötigte Zeit, um sicherzustellen, dass die `Init`- und `Invoke`-Phase innerhalb der konfigurierten Zeitspanne abgeschlossen werden kann. ## IAM: Lambda: InvokeFunction nicht autorisiert **Fehler: Benutzer:** *arn:aws:iam: :123456789012:user/developer ist nicht berechtigt, Folgendes auszuführen: lambda*: on resource: my-function InvokeFunction Ihr Benutzer oder die Rolle, die Sie annehmen, muss über die Berechtigung zum Aufrufen einer Funktion verfügen. Diese Anforderung gilt auch für Lambda-Funktionen und andere Datenverarbeitungsressourcen, die Funktionen aufrufen. Fügen Sie Ihrem Benutzer die **AWSLambdaRolle der AWS verwalteten Richtlinie hinzu, oder fügen Sie eine benutzerdefinierte** Richtlinie hinzu, die die Aktion für die Zielfunktion ermöglicht. `lambda:InvokeFunction` **Anmerkung** Der Name der IAM-Aktion (`lambda:InvokeFunction`) bezieht sich auf den `Invoke`-Lambda-API-Vorgang. Weitere Informationen finden Sie unter [Verwaltung von Berechtigungen in AWS Lambda](lambda-permissions.md). ## Lambda: Es konnte kein gültiger Bootstrap gefunden werden (Runtime). InvalidEntrypoint) **Fehler:** Es *konnten keine gültigen Bootstrap (s) gefunden werden: [/var/task/bootstrap /opt/bootstrap]* Dieser Fehler tritt normalerweise auf, wenn das Stammverzeichnis Ihres Bereitstellungspakets keine ausführbare Datei mit dem Namen `bootstrap` enthält. Wenn Sie beispielsweise eine `provided.al2023`-Funktion über eine ZIP-Datei bereitstellen, muss sich die `bootstrap`-Datei im Stammverzeichnis der ZIP-Datei befinden, nicht in einem Verzeichnis. ## Lambda: Vorgang kann nicht ausgeführt werden ResourceConflictException **FehlerResourceConflictException:** *Der Vorgang kann derzeit nicht ausgeführt werden. Die Funktion befindet sich derzeit in folgendem Zustand: Ausstehend* Wenn Sie zum Zeitpunkt der Erstellung eine Funktion mit einer Virtual Private Cloud (VPC) verbinden, wechselt die Funktion in einen `Pending`-Zustand, während Lambda Elastic-Network-Schnittstellen erstellt. Während dieser Zeit können Sie Ihre Funktion nicht aufrufen oder ändern. Wenn Sie Ihre Funktion nach der Erstellung mit einer VPC verbinden, können Sie sie aufrufen, während das Update aussteht, aber Sie können den Code oder die Konfiguration nicht ändern. Weitere Informationen finden Sie unter [Lambda-Funktionszustände](functions-states.md). ## Lambda: Funktion bleibt im Status Pending **Fehler:** *Eine Funktion bleibt mehrere Minuten im `Pending`-Zustand.* Wenn eine Funktion länger als sechs Minuten im `Pending`-Zustand ist, rufen Sie eine der folgenden API-Operationen auf, um die Blockierung aufzuheben. + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) Lambda bricht den ausstehenden Vorgang ab und versetzt die Funktion in den `Failed`-Zustand. Sie können dann versuchen, eine weitere Aktualisierung durchzuführen. ## Lambda: Eine Funktion verwendet alle Parallelität **Problem:** *Eine Funktion verwendet die gesamte verfügbare Gleichzeitigkeit, wodurch andere Funktionen gedrosselt werden.* Um die verfügbare Parallelität Ihres AWS Kontos in einer AWS Region in Pools aufzuteilen, verwenden Sie [reservierte Parallelität](configuration-concurrency.md). Durch reservierte Gleichzeitigkeit wird sichergestellt, dass eine Funktion immer auf ihre zugewiesene Gleichzeitigkeit skalieren kann und nicht über die zugewiesene Gleichzeitigkeit hinaus skaliert wird. ## Allgemein: Funktion kann nicht mit anderen Konten oder Diensten aufgerufen werden **Problem:** *Sie können Ihre Funktion direkt aufrufen. Sie wird jedoch nicht ausgeführt, wenn sie von einem anderen Service oder Konto aufgerufen wird.* Sie erteilen [anderen Services](lambda-services.md) und Konten die Berechtigung zum Aufrufen einer Funktion in der [ressourcenbasierten Richtlinie](access-control-resource-based.md)der Funktion. Wenn sich der Aufrufer in einem anderen Konto befindet, benötigt dieser Benutzer auch die [Berechtigung zum Aufrufen von Funktionen](access-control-identity-based.md). ## Allgemein: Funktionsaufruf bleibt im Looping **Problem:** *Die Funktion wird kontinuierlich in einer Schleife aufgerufen.* Dies ist in der Regel der Fall, wenn Ihre Funktion Ressourcen in demselben AWS Dienst verwaltet, der sie auslöst. Beispielsweise ist es möglich, eine Funktion zu erstellen, die ein Objekt in einem Bucket von Amazon Simple Storage Service (Amazon S3) speichert, der mit einer [Benachrichtigung konfiguriert ist, die die Funktion erneut aufruft](with-s3.md). Um die Ausführung der Funktion zu stoppen, reduzieren Sie die verfügbare [Gleichzeitigkeit](lambda-concurrency.md) auf Null, wodurch alle zukünftigen Aufrufe gedrosselt werden. Identifizieren Sie dann den Codepfad oder Konfigurationsfehler, der den rekursiven Aufruf verursacht hat. Lambda erkennt und stoppt automatisch rekursive Schleifen für einige AWS Dienste und. SDKs Weitere Informationen finden Sie unter [Verwenden Sie die rekursive Lambda-Schleifenerkennung, um Endlosschleifen zu verhindern](invocation-recursion.md). ## Lambda: Alias-Routing mit bereitgestellter Parallelität **Problem:** *Bereitgestellte Parallelitäts-Überlauf-Aufrufe während des Alias-Routings.* Lambda verwendet ein einfaches probabilistisches Modell, um den Datenverkehr zwischen den beiden Funktionsversionen zu verteilen. Bei niedrigem Datenverkehr sehen Sie möglicherweise eine hohe Abweichung zwischen dem konfigurierten und dem tatsächlichen Prozentsatz des Datenverkehrs für jede Version. Wenn Ihre Funktion bereitgestellte Parallelität verwendet, können Sie [Überlaufaufrufe](monitoring-metrics-types.md#invocation-metrics) durch Konfigurieren einer höheren Anzahl von bereitgestellten Parallelitätsinstances während des aktiven Alias-Routings vermeiden. ## Lambda: Kaltstarts mit bereitgestellter Parallelität ** Problem:** *Sie erleben Kaltstarts nach dem Aktivieren der bereitgestellten Parallelität.* Wenn die Anzahl der gleichzeitigen Ausführungen einer Funktion kleiner oder gleich der [konfigurierten Ebene der bereitgestellten Parallelität](provisioned-concurrency.md) ist, sollte es keine Kaltstarts geben. Um Ihnen zu helfen zu bestätigen, ob die bereitgestellte Parallelität normal funktioniert, gehen Sie wie folgt vor: + [Überprüfen Sie, ob die bereitgestellte Parallelität](provisioned-concurrency.md) auf der Funktionsversion oder dem Alias aktiviert ist. **Anmerkung** Die bereitgestellte Gleichzeitigkeit kann in der unveröffentlichten [Version der Funktion](configuration-versions.md) nicht konfiguriert werden. + Stellen Sie sicher, dass Ihre Auslöser die richtige Funktionsversion oder den richtigen Alias aufrufen. Wenn Sie zum Beispiel Amazon API Gateway verwenden, überprüfen Sie, dass Amazon API die Funktionsversion oder den Alias mit bereitgestellter Parallelität aufruft, nicht \$1LATEST. Um zu überprüfen, ob die bereitgestellte Parallelität verwendet wird, können Sie die [ProvisionedConcurrencyInvocations CloudWatch Amazon-Metrik](monitoring-concurrency.md#provisioned-concurrency-metrics) überprüfen. Ein Wert ungleich Null gibt an, dass die Funktion Aufrufe in initialisierten Ausführungsumgebungen verarbeitet. + [Stellen Sie anhand der Metrik fest, ob Ihre Funktionsparallelität die konfigurierte Stufe der bereitgestellten Parallelität überschreitet. ProvisionedConcurrencySpilloverInvocations CloudWatch](monitoring-concurrency.md#provisioned-concurrency-metrics) Ein Wert ungleich Null gibt an, dass die gesamte bereitgestellte Parallelität verwendet wird und einige Aufrufe mit einem Kaltstart stattgefunden haben. + Überprüfen Sie Ihre [Aufrufhäufigkeit](gettingstarted-limits.md#api-requests) (Anfragen pro Sekunde) Funktionen mit bereitgestellter Parallelität haben eine maximale Rate von 10 Anfragen pro Sekunde pro bereitgestellte Parallelität. Beispielsweise kann eine Funktion, die mit 100 bereitgestellter Parallelität konfiguriert ist, 1.000 Anfragen pro Sekunde bearbeiten. Wenn die Aufrufrate 1.000 Anfragen pro Sekunde übersteigt, kann es zu Kaltstarts kommen. ## Lambda: Kaltstarts mit neuen Versionen **Problem:** *Sie erleben Kaltstarts, wenn Sie neue Versionen Ihrer Funktion bereitstellen.* Wenn Sie einen Funktionsalias aktualisieren, verschiebt Lambda die bereitgestellte Parallelität basierend auf den für den Alias konfigurierten Gewichtungen automatisch auf die neue Version. **Fehler: KMSDisabled** *Ausnahme: Lambda konnte die Umgebungsvariablen nicht entschlüsseln, da der verwendete KMS-Schlüssel deaktiviert ist. Bitte überprüfen Sie die KMS-Schlüsseleinstellungen der Funktion.* Dieser Fehler kann auftreten, wenn Ihr AWS Key Management Service (AWS KMS) -Schlüssel deaktiviert ist oder wenn die Genehmigung, die Lambda die Verwendung des Schlüssels ermöglicht, widerrufen wird. Wenn die Gewährung fehlt, konfigurieren Sie die Funktion so, dass sie einen anderen Schlüssel verwendet. Weisen Sie dann den benutzerdefinierten Schlüssel neu zu, um die Erteilung neu zu erstellen. ## Lambda: Unerwartetes Beenden von Node.js während der Laufzeit (Runtime). NodejsExit) **Problem:** Der *Lambda-Runtime-Client hat einen unerwarteten Exit-Code für Node.js erkannt*. Dieser Fehler tritt auf, wenn Ihre Funktion beendet wird, bevor alle Versprechen erfüllt sind, z. B. aufgrund eines Codefehlers. Er kann auch auftreten, wenn Node.js einen Deadlock erkennt, der verhindert, dass Promises abgewickelt werden können. Dieser Fehler betrifft nur Handler im asynchronen Stil, nicht Handler im Callback-Stil. **Betroffene Laufzeiten**: Node.js 18 und höher. **Um dieses Problem zu lösen:** 1. Überprüfen Sie Ihren Funktionscode auf ungeklärte Versprechen in asynchronen Handlern. 1. Stellen Sie sicher, dass alle Versprechen ordnungsgemäß erfüllt (gelöst oder abgelehnt) wurden, bevor die Funktion abgeschlossen ist. 1. Überprüfen Sie Ihren Code auf mögliche Rennbedingungen bei asynchronen Vorgängen. Weitere Informationen zu den Exit-Codes von Node.js und zur Beendigung von Prozessen finden Sie in der [Dokumentation zu Node.js](https://nodejs.org/docs/latest/api/process.html#exit-codes). ## EFS: Die Funktion konnte das EFS-Dateisystem nicht mounten **Fehler EFSMountFailureException:** *Die Funktion konnte das EFS-Dateisystem mit dem Access Point arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd nicht mounten*. Die Mounting-Anforderung der Funktion an das Dateisystem wurde abgelehnt. Überprüfen Sie die Berechtigungen der Funktion und bestätigen Sie, dass das Dateisystem und der Zugriffspunkt vorhanden und einsatzbereit sind. ## EFS: Die Funktion konnte keine Verbindung zum EFS-Dateisystem herstellen **Fehler EFSMountConnectivityException:** *Die Funktion konnte keine Verbindung zum Amazon EFS-Dateisystem mit dem Access Point arn:aws:elasticfilesystem:us-east - 2:123456789012:access-point/fsap-015cxmplb72b405fd herstellen. Überprüfen Sie die Netzwerkkonfiguration und versuchen Sie es erneut.* Die Funktion konnte keine Verbindung zum Dateisystem der Funktion mit dem NFS-Protokoll (TCP-Port 2049) herstellen. Überprüfen Sie die [Sicherheitsgruppe und die Routingkonfiguration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-prereq-policies.html) für die Subnetze der VPC. Wenn Sie diese Fehler nach der Aktualisierung der VPC-Konfigurationseinstellungen Ihrer Funktion erhalten, versuchen Sie, das Dateisystem auszuhängen und erneut auszuhängen. ## EFS: Die Funktion konnte das EFS-Dateisystem aufgrund eines Timeouts nicht mounten **Fehler EFSMountTimeoutException:** *Die Funktion konnte das EFS-Dateisystem mit dem Access Point \$1arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd\$1 aufgrund eines Mount-Timeouts* nicht mounten. Die Funktion konnte eine Verbindung mit dem Dateisystem der Funktion herstellen, aber bei der Mounting-Operation trat eine Zeitüberschreitung auf. Versuchen Sie es nach kurzer Zeit erneut und erwägen Sie, die [Nebenläufigkeit](configuration-concurrency.md) der Funktion zu begrenzen, um die Belastung des Dateisystems zu reduzieren. ## S3-Dateien: Die Funktion konnte das S3-Dateisystem nicht mounten **Fehler: S3FilesMountFailureException:** *Die Funktion konnte das Amazon S3 S3-Dateisystem mit dem Access Point arn:aws:s3files:us-east- 2:123456789012:access-point/fsap-123456789abcde nicht mounten*. Die Mounting-Anforderung der Funktion an das Dateisystem wurde abgelehnt. Überprüfen Sie die Berechtigungen der Funktion und bestätigen Sie, dass das Dateisystem und der Zugriffspunkt vorhanden und einsatzbereit sind. ## S3-Dateien: Die Funktion konnte keine Verbindung zum S3-Dateisystem herstellen **Fehler: S3FilesMountConnectivityException:** *Die Funktion konnte keine Verbindung zum Amazon S3 S3-Dateisystem mit dem Access Point arn:aws:s3files:us-east - 2:123456789012:access-point/fsap-123456789abcde herstellen. Überprüfen Sie die Netzwerkkonfiguration und versuchen Sie es erneut.* Die Funktion konnte keine Verbindung zum Dateisystem der Funktion mit dem NFS-Protokoll (TCP-Port 2049) herstellen. Überprüfen Sie die [Sicherheitsgruppe und die Routingkonfiguration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-prereq-policies.html) für die Subnetze der VPC. Wenn Sie diese Fehler nach der Aktualisierung der VPC-Konfigurationseinstellungen Ihrer Funktion erhalten, versuchen Sie, das Dateisystem auszuhängen und erneut auszuhängen. ## S3-Dateien: Die Funktion konnte das S3-Dateisystem aufgrund eines Timeouts nicht mounten **Fehler: S3FilesMountTimeoutException:** *Die Funktion konnte das S3-Dateisystem mit dem Access Point \$1arn:aws:s3files:us-east- 2:123456789012:access-point/fsap-123456789abcde\$1 aufgrund eines Mount-Timeouts* nicht mounten. Die Funktion konnte eine Verbindung mit dem Dateisystem der Funktion herstellen, aber bei der Mounting-Operation trat eine Zeitüberschreitung auf. Versuchen Sie es nach kurzer Zeit erneut und erwägen Sie, die [Nebenläufigkeit](configuration-concurrency.md) der Funktion zu begrenzen, um die Belastung des Dateisystems zu reduzieren. ## Lambda: Lambda hat einen IO-Prozess erkannt, der zu lange dauerte *EFSIOException: Diese Funktionsinstanz wurde gestoppt, weil Lambda einen IO-Prozess erkannt hat, der zu lange dauerte.* Bei einem vorherigen Aufruf trat eine Zeitüberschreitung auf und Lambda konnte den Funktions-Handler nicht beenden. Dieses Problem kann auftreten, wenn ein angehängtes Dateisystem keine Burst-Credits hat und der Basisdurchsatz nicht ausreicht. Um den Durchsatz zu erhöhen, können Sie die Größe des Dateisystems erhöhen oder den bereitgestellten Durchsatz verwenden. ## Container: Fehler CodeArtifactUserException **Fehler: CodeArtifactUserPendingException ** *Fehlermeldung* Die Optimierung CodeArtifact steht noch aus. Die Funktion wechselt in den [aktiven Zustand](functions-states.md), wenn Lambda die Optimierung abgeschlossen hat. HTTP-Antwortcode 409. **Fehler: CodeArtifactUserDeletedException ** *Fehlermeldung* CodeArtifact Es ist geplant, dass das gelöscht wird. HTTP-Antwortcode 409. **Fehler: CodeArtifactUserFailedException ** *Fehlermeldung* Lambda konnte den Code nicht optimieren. Sie müssen den Code korrigieren und erneut hochladen. HTTP-Antwortcode 409. ## Container: InvalidEntrypoint Fehler **Fehler:** *Laufzeit. ExitError oder „errorType“: „Runtime. InvalidEntrypoint„* Stellen Sie sicher, dass der ENTRYPOINT zu Ihrem Container-Image den absoluten Pfad als Standort enthält. Stellen Sie außerdem sicher, dass das Image keinen Symlink als ENTRYPOINT enthält. **Fehler:** *Sie verwenden eine CloudFormation Vorlage und Ihr Container-ENTRYPOINT wird mit einem Nullwert oder einem leeren Wert überschrieben*. Überprüfen Sie die [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html)Ressource in der Vorlage. CloudFormation Wenn Sie eine `ImageConfig`-Ressource in Ihrer Vorlage deklarieren, müssen Sie nichtleere Werte für alle drei Eigenschaften angeben. # Beheben von Ausführungsproblemen in Lambda Wenn die Lambda-Laufzeitumgebung Ihren Funktionscode ausführt, wird das Ereignis möglicherweise auf einer Instance der Funktion verarbeitet, auf der schon länger Ereignisse verarbeitet werden, oder muss möglicherweise eine neue Instance initialisiert werden. Fehler können während der Funktionsinitialisierung, wenn Ihr Handler-Code das Ereignis verarbeitet oder wenn Ihre Funktion eine Antwort zurückgibt (oder nicht zurückgibt), auftreten. Funktionsausführungsfehler können durch Probleme mit Code, Funktionskonfiguration, nachgeschalteten Ressourcen oder Berechtigungen verursacht werden. Wenn Sie Ihre Funktion direkt aufrufen, sehen Sie Funktionsfehler in der Antwort von Lambda. Wenn Sie Ihre Funktion asynchron mit einer Ereignisquellen-Zuweisung oder über einen anderen Service aufrufen, finden Sie möglicherweise Fehler in Protokollen, eine Warteschlange für unzustellbare Nachrichten oder ein Ziel bei Ausfall. Die Optionen für die Fehlerbehandlung und das Wiederholungsverhalten variieren je nachdem, wie Sie Ihre Funktion aufrufen, und nach der Art des Fehlers. Wenn Ihr Funktionscode oder die Lambda-Laufzeit einen Fehler zurückgibt, ist der Statuscode in der Antwort von Lambda „200 OK“. Das Vorhandensein eines Fehlers in der Antwort wird durch einen Header namens `X-Amz-Function-Error` angezeigt. Statuscodes der Serien 400 und 500 sind für [Aufruffehler](troubleshooting-invocation.md) reserviert. **Topics** + [Lambda: Remote-Debugging mit Visual Studio Code](#troubleshooting-execution-remote-debugging) + [Lambda: Die Ausführung dauert zu lange](#troubleshooting-execution-toolong) + [Lamda: Unerwartete Ereignis-Nutzdaten](#troubleshooting-execution-unexpected-payload) + [Lambda: Unerwartet große Nutzdaten](#troubleshooting-execution-large-payload) + [Lambda: Fehler beim Kodieren und Dekodieren von JSON](#troubleshooting-execution-json-encoding) + [Lambda: Protokolle oder Ablaufverfolgungen erscheinen nicht](#troubleshooting-execution-logstraces) + [Lambda: Nicht alle Protokolle meiner Funktion werden angezeigt](#troubleshooting-execution-missinglogs) + [Lambda: Die Funktion kehrt zurück, bevor die Ausführung beendet ist](#troubleshooting-execution-unfinished) + [Lamda: Ausführen einer unbeabsichtigten Funktionsversion oder eines Alias](#unintended-function) + [Lambda: Erkennen von Endlosschleifen](#infinite-loops) + [Allgemein: Nichtverfügbarkeit nachgelagerter Dienste](#downstream-unavailability) + [AWS SDK: Versionen und Updates](#troubleshooting-execution-versions) + [Python: Bibliotheken werden falsch geladen](#troubleshooting-execution-libraries) + [Java: Ihre Funktion braucht länger, um Ereignisse zu verarbeiten, nachdem sie von Java 11 auf Java 17 aktualisiert wurde](#troubleshooting-execution-java-perf) + [Kafka: Probleme bei der Fehlerbehandlung und beim erneuten Versuch der Konfiguration](#troubleshooting-kafka-error-handling) ## Lambda: Remote-Debugging mit Visual Studio Code **Problem:** *Schwierigkeiten bei der Behebung des komplexen Verhaltens von Lambda-Funktionen in der tatsächlichen Umgebung AWS * Lambda bietet ein Remote-Debugging-Feature über das AWS Toolkit for Visual Studio Code. Anweisungen zur Einrichtung und allgemeinen Nutzung finden Sie unter [Remote-Debugging von Lambda-Funktionen mit Visual Studio Code](debugging.md). Ausführliche Anweisungen zur Fehlerbehebung, zu erweiterten Anwendungsfällen und zur regionalen Verfügbarkeit finden Sie unter [Lambda-Funktionen per Fernzugriff](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) im AWS Toolkit for Visual Studio Code Benutzerhandbuch. ## Lambda: Die Ausführung dauert zu lange **Problem:** *Die Ausführung der Funktion dauert zu lange.* Wenn die Ausführung Ihres Codes in Lambda viel länger dauert als auf Ihrem lokalen Computer, kann er durch den der Funktion zur Verfügung stehenden Speicher oder die Rechenleistung eingeschränkt sein. [Konfigurieren Sie die Funktion mit zusätzlichem Arbeitsspeicher](configuration-memory.md), um sowohl Arbeitsspeicher als auch CPU zu erhöhen. ## Lamda: Unerwartete Ereignis-Nutzdaten **Problem:** *Funktionsfehler im Zusammenhang mit fehlerhaftem JSON oder unzureichender Datenvalidierung* Alle Lambda-Funktionen erhalten eine Ereignis-Nutzdaten im ersten Parameter des Handlers. Die Ereignis- Nutzdaten sind eine JSON-Struktur, die Arrays und verschachtelte Elemente enthalten kann. Missgebildetes JSON kann auftreten, wenn es von vorgelagerten Diensten bereitgestellt wird, die kein robustes Verfahren zur Überprüfung von JSON-Strukturen verwenden. Dies tritt auf, wenn Dienste Textzeichenfolgen miteinander verknüpfen oder Benutzereingaben einbetten, die nicht bereinigt wurden. JSON wird auch häufig für die Weitergabe zwischen Diensten serialisiert. Analysieren Sie JSON-Strukturen immer sowohl als Produzent als auch als Nutzer von JSON, um sicherzustellen, dass die Struktur gültig ist. Ebenso kann es zu Fehlern kommen, wenn nicht auf Wertebereiche in den Ereignis-Nutzdaten geprüft wird. Eine Funktion, die an den Wert des Handlers übergeben wird: ``` exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) } ``` Diese Funktion verwendet ein Gehalt und einen Steuersatz aus den Ereignis-Nutzdaten, um die Berechnung durchzuführen. Der Code überprüft jedoch nicht, ob die Attribute vorhanden sind. Außerdem werden Datentypen nicht überprüft oder Grenzen nicht gewährleistet, z. B. die Sicherstellung, dass der Steuersatz zwischen 0 und 1 liegt. Daher führen Werte außerhalb dieser Grenzen zu unsinnigen Ergebnissen. Ein falscher Typ oder ein fehlendes Attribut führt zu einem Laufzeitfehler. Erstellen Sie Tests, um sicherzustellen, dass Ihre Funktion größere Nutzdaten verarbeitet. Die maximale Größe für eine Lambda-Ereignis-Nutzlast beträgt 1 MB. Je nach Inhalt können größere Nutzdaten bedeuten, dass mehr Elemente an die Funktion übergeben werden oder dass mehr Binärdaten in ein JSON-Attribut eingebettet sind. In beiden Fällen kann dies zu mehr Verarbeitung für eine Lambda-Funktion führen. Größere Nutzdaten können auch zu Timeouts führen. Eine Lambda-Funktion verarbeitet beispielsweise einen Datensatz pro 100 ms und hat ein Timeout von 3 Sekunden. Die Verarbeitung ist für 0-29 Elemente in den Nutzdaten erfolgreich. Sobald die Nutzdaten jedoch mehr als 30 Elemente enthalten, bricht die Funktion ab und gibt einen Fehler aus. Um dies zu vermeiden, stellen Sie sicher, dass die Timeouts so eingestellt sind, dass sie die zusätzliche Verarbeitungszeit für die maximale Anzahl erwarteter Elemente berücksichtigen. ## Lambda: Unerwartet große Nutzdaten **Problem:** *Funktionen verursachen Timeouts und Fehler aufgrund großer Nutzdaten* Größere Nutzdaten können zu Timeouts und Fehlern führen. Wir empfehlen, Tests zu erstellen, um sicherzustellen, dass Ihre Funktion die größten zu erwartenden Nutzdaten verarbeiten kann, und zu prüfen, ob das Zeitlimit für die Funktion richtig eingestellt ist. Darüber hinaus können bestimmte Ereignis-Nutzdaten Verweise auf andere Ressourcen enthalten. Beispielsweise kann eine Lambda-Funktion mit 128 MB Speicher eine Bildverarbeitung für eine JPG-Datei durchführen, die als Objekt in S3 gespeichert ist. Die Funktion funktioniert erwartungsgemäß mit kleineren Bilddateien. Wenn jedoch eine größere JPG-Datei als Eingabe bereitgestellt wird, gibt die Lambda-Funktion einen Fehler aus, da nicht genügend Speicherplatz zur Verfügung steht. Um dies zu vermeiden, sollten die Testfälle Beispiele aus dem oberen Bereich der erwarteten Datengrößen enthalten. Der Code sollte auch die Nutzdatengröße validieren. ## Lambda: Fehler beim Kodieren und Dekodieren von JSON **Problem: NoSuchKey ** *Ausnahme beim Parsen* von JSON-Eingaben. Stellen Sie sicher, dass Sie JSON-Attribute korrekt verarbeiten. Für Ereignisse, die von S3 generiert wurden, enthält das Attribut `s3.object.key` beispielsweise einen URL-codierten Objektschlüsselnamen. Viele Funktionen verarbeiten dieses Attribut als Text, um das referenzierte S3-Objekt zu laden: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise() ``` Dieser Code funktioniert mit dem Schlüsselnamen `james.jpg`, löst aber einen `NoSuchKey`-Fehler aus, wenn der Name `james beswick.jpg` lautet. Da die URL-Kodierung Leerzeichen und andere Zeichen in einem Schlüsselnamen konvertiert, müssen Sie sicherstellen, dass Funktionen Schlüssel dekodieren, bevor Sie diese Daten verwenden: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise() ``` ## Lambda: Protokolle oder Ablaufverfolgungen erscheinen nicht **Problem:** *Protokolle werden nicht in CloudWatch Logs angezeigt*. **Problem:** *Spuren werden nicht in angezeigt AWS X-Ray.* Ihre Funktion benötigt die Erlaubnis, CloudWatch Logs und X-Ray aufzurufen. Aktualisieren Sie die [Ausführungsrolle](lambda-intro-execution-role.md), um ihr die Berechtigung zu erteilen. Fügen Sie die folgenden verwalteten Richtlinien hinzu, um Protokolle und Ablaufverfolgung zu aktivieren. + **AWSLambdaBasicExecutionRole** + **AWSXRayDaemonWriteAccess** Wenn Sie Ihrer Funktion Berechtigungen hinzufügen, führen Sie auch eine triviale Aktualisierung ihres Codes oder ihrer Konfiguration durch. Dies zwingt ausgeführte Instances Ihrer Funktion, die veraltete Anmeldeinformationen haben, anzuhalten und ersetzt zu werden. **Anmerkung** Es kann 5 bis 10 Minuten dauern, bis Protokolle nach einem Funktionsaufruf angezeigt werden. ## Lambda: Nicht alle Protokolle meiner Funktion werden angezeigt **Problem:** *Funktionsprotokolle fehlen in CloudWatch Logs, obwohl meine Berechtigungen korrekt sind* Wenn Ihr System die [Kontingentgrenzen für CloudWatch Logs AWS-Konto](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) erreicht, wird die Funktionsprotokollierung CloudWatch gedrosselt. In diesem Fall werden einige der von Ihren Funktionen ausgegebenen Protokolle möglicherweise nicht in CloudWatch den Protokollen angezeigt. Wenn Ihre Funktion Logs mit einer zu hohen Rate ausgibt, als dass Lambda sie verarbeiten könnte, kann dies auch dazu führen, dass Protokollausgaben nicht in CloudWatch Logs erscheinen. Wenn Lambda Protokolle nicht mit der Geschwindigkeit senden kann, CloudWatch an die Ihre Funktion sie generiert, werden Protokolle gelöscht, um zu verhindern, dass die Ausführung Ihrer Funktion verlangsamt wird. Gehen Sie davon aus, dass gelöschte Protokolle konsistent beobachtet werden, wenn Ihr Protokolldurchsatz MB/s für einen einzelnen Protokollstream 2 überschreitet. Wenn Ihre Funktion für die Verwendung von [Protokollen im JSON-Format](monitoring-cloudwatchlogs-logformat.md) konfiguriert ist, versucht Lambda, beim Löschen von Protokollen ein [`logsDropped`](telemetry-schema-reference.md#platform-logsDropped)Ereignis an CloudWatch Logs zu senden. Wenn jedoch die Protokollierung Ihrer Funktion CloudWatch gedrosselt wird, erreicht dieses Ereignis möglicherweise nicht CloudWatch Logs, sodass Sie nicht immer einen Datensatz sehen, wenn Lambda Logs löscht. Gehen Sie wie folgt vor, um zu überprüfen, ob Ihr System die Kontingentgrenzen für CloudWatch Logs erreicht AWS-Konto hat: 1. Öffnen Sie die [Service Quotas-Konsole](https://console.aws.amazon.com/servicequotas). 1. Wählen Sie im Navigationsbereich **AWS -Services**. 1. Suchen Sie in der **AWS Serviceliste** nach Amazon CloudWatch Logs. 1. Wählen Sie in der Liste mit den **Service Quotas** die Kontingente `CreateLogGroup throttle limit in transactions per second`, `CreateLogStream throttle limit in transactions per second` und `PutLogEvents throttle limit in transactions per second` aus, um die Auslastung anzuzeigen. Sie können auch CloudWatch Alarme einrichten, die Sie benachrichtigen, wenn Ihre Kontoauslastung ein von Ihnen für diese Kontingente festgelegtes Limit überschreitet. Weitere Informationen finden [Sie unter Einen CloudWatch Alarm auf der Grundlage eines statischen Schwellenwerts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) erstellen. Wenn die standardmäßigen Kontingentgrenzen für CloudWatch Logs für Ihren Anwendungsfall nicht ausreichen, können Sie [eine Erhöhung des Kontingents beantragen](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). ## Lambda: Die Funktion kehrt zurück, bevor die Ausführung beendet ist **Problem: (Node.js)** *Rückgabe der Funktion erfolgt, bevor Code ausgeführt wird* Viele Bibliotheken, einschließlich des AWS SDK, arbeiten asynchron. Wenn Sie einen Netzwerkaufruf tätigen oder einen anderen Vorgang ausführen, für den auf eine Antwort gewartet werden muss, geben Bibliotheken ein Objekt zurück, das als Zusage bezeichnet wird und mit dem der Status der Operation im Hintergrund nachverfolgt wird. Um zu warten, bis die Zusage in eine Antwort aufgelöst wird, verwenden Sie das Schlüsselwort `await`. Dadurch wird verhindert, dass der Handler-Code ausgeführt wird, bis die Zusage in ein Objekt aufgelöst wird, das die Antwort enthält. Wenn Sie die Daten aus der Antwort in Ihrem Code nicht verwenden müssen, können Sie die Zusage direkt an die Laufzeit zurückgeben. Einige Bibliotheken geben keine Zusagen zurück, können aber in Code verpackt werden, der dies tut. Weitere Informationen finden Sie unter [Lambda-Funktionshandler in Node.js definieren](nodejs-handler.md). ## Lamda: Ausführen einer unbeabsichtigten Funktionsversion oder eines Alias **Problem:** *Funktionsversion oder Alias wurde nicht aufgerufen* Wenn Sie neue Lambda-Funktionen in der Konsole veröffentlichen oder verwenden AWS SAM, wird die neueste Codeversion durch `$LATEST` dargestellt. Standardmäßig zielen Aufrufe, die keine Version oder keinen Alias angeben, automatisch auf die `$LATEST`-Version Ihres Funktionscodes ab. Wenn Sie bestimmte Funktionsversionen oder Aliase verwenden, handelt es sich dabei um unveränderliche veröffentlichte Versionen einer Funktion zusätzlich zu `$LATEST`. Stellen Sie bei der Problembehebung dieser Funktionen zunächst fest, ob der Aufrufer die beabsichtigte Version oder den Alias aufgerufen hat. Überprüfen Sie dazu Ihre Funktionsprotokolle. Die Version der aufgerufenen Funktion wird immer in der START-Protokollzeile angezeigt: ![\[Debugging-Operationen, Abbildung 1\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-1.png) ## Lambda: Erkennen von Endlosschleifen **Problem:** *Endlosschleifenmuster im Zusammenhang mit Lambda-Funktionen* Es gibt zwei Arten von Endlosschleifen in Lambda-Funktionen. Die erste befindet sich innerhalb der Funktion selbst und wird durch eine Schleife verursacht, die niemals beendet wird. Der Aufruf endet erst, wenn die Funktion ein Timeout verursacht. Sie können diese identifizieren, indem Sie Timeouts überwachen und dann das Schleifenverhalten beheben. Die zweite Art von Schleife besteht zwischen Lambda-Funktionen und anderen AWS Ressourcen. Diese treten auf, wenn ein Ereignis aus einer Ressource wie einem S3-Bucket eine Lambda-Funktion aufruft, die dann mit derselben Quellressource interagiert, um ein weiteres Ereignis auszulösen. Dadurch wird die Funktion erneut aufgerufen, wodurch eine weitere Interaktion mit demselben S3-Bucket erstellt wird, und so weiter. Diese Arten von Schleifen können durch eine Reihe verschiedener AWS Ereignisquellen verursacht werden, darunter Amazon SQS SQS-Warteschlangen und DynamoDB-Tabellen. Sie können diese Muster mithilfe der [rekursiven Schleifenerkennung](invocation-recursion.md) identifizieren. ![\[Debugging-Operationen, Abbildung 2\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-2.png) Sie können diese Schleifen vermeiden, indem Sie sicherstellen, dass Lambda-Funktionen in Ressourcen schreiben, die nicht mit der verbrauchenden Ressource identisch sind. Wenn Sie Daten wieder auf der verbrauchenden Ressource veröffentlichen müssen, stellen Sie sicher, dass die neuen Daten nicht dasselbe Ereignis auslösen. Verwenden Sie alternativ die [Ereignisfilterung](invocation-eventfiltering.md). Hier sind beispielsweise zwei Lösungsvorschläge für Endlosschleifen mit S3- und DynamoDB-Ressourcen: + Wenn Sie in denselben S3-Bucket zurückschreiben, verwenden Sie ein anderes Präfix oder Suffix als beim Ereignisauslöser. + Wenn Sie Elemente in dieselbe DynamoDB-Tabelle schreiben, fügen Sie ein Attribut hinzu, nach dem eine verbrauchende Lambda-Funktion filtern kann. Wenn Lambda das Attribut findet, führt dies nicht zu einem weiteren Aufruf. ## Allgemein: Nichtverfügbarkeit nachgelagerter Dienste **Problem:** *Die nachgelagerten Dienste, auf die Ihre Lambda-Funktion angewiesen ist, sind nicht verfügbar* Stellen Sie bei Lambda-Funktionen, die Drittanbieter-Endpunkte oder andere nachgelagerte Ressourcen aufrufen, sicher, dass sie Servicefehler und Timeouts behandeln können. Diese nachgelagerten Ressourcen können unterschiedliche Reaktionszeiten haben oder aufgrund von Serviceunterbrechungen nicht verfügbar sein. Je nach Implementierung können diese nachgelagerten Fehler als Lambda-Timeouts oder Ausnahmen erscheinen, wenn die Fehlerantwort des Dienstes nicht im Code der Funktion behandelt wird. Implementieren Sie eine geeignete Fehlerbehandlung und Wiederholungslogik, wenn eine Funktion von einem nachgelagerten Dienst abhängt, z. B. von einem API-Aufruf. Für kritische Dienste sollte die Lambda-Funktion Metriken oder Protokolle veröffentlichen. CloudWatch Wenn beispielsweise eine Zahlungs-API eines Drittanbieters nicht mehr verfügbar ist, kann die Lambda-Funktion diese Informationen protokollieren. Sie können dann CloudWatch Alarme einrichten, um Benachrichtigungen zu diesen Fehlern zu senden. Da Lambda schnell skalieren kann, können nachgelagerte Dienste, die nicht Serverless sind, Schwierigkeiten haben, Datenverkehrsspitzen zu bewältigen. Es gibt drei gängige Ansätze, um damit umzugehen: + **Caching**: Erwägen Sie, die Ergebnisse von Werten, die von Drittanbieterdiensten zurückgegeben werden, zwischenzuspeichern, wenn diese sich nicht häufig ändern. Sie können diese Werte in einer globalen Variablen in Ihrer Funktion oder einem anderen Dienst speichern. Beispielsweise könnten die Ergebnisse einer Produktlistenabfrage von einer Amazon RDS-Instance innerhalb der Funktion für einen bestimmten Zeitraum gespeichert werden, um redundante Abfragen zu vermeiden. + **Warteschlangen**: Fügen Sie beim Speichern oder Aktualisieren von Daten eine Amazon-SQS-Warteschlange zwischen der Lambda-Funktion und der Ressource hinzu. In der Warteschlange werden Daten dauerhaft gespeichert, während der nachgelagerte Dienst Nachrichten verarbeitet. + **Proxys**: Wenn in der Regel langlebige Verbindungen verwendet werden, z. B. für Amazon-RDS-Instances, verwenden Sie eine Proxyebene, um diese Verbindungen zu bündeln und wiederzuverwenden. Für relationale Datenbanken ist [Amazon-RDS-Proxy](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository) ein Service, der dazu beitragen soll, die Skalierbarkeit und Stabilität von Lambda–basierten Anwendungen zu verbessern. ## AWS SDK: Versionen und Updates **Problem:** *Das in der Runtime enthaltene AWS SDK ist nicht die neueste Version* **Problem:** *Das in der Runtime enthaltene AWS SDK wird automatisch aktualisiert* Zu den Laufzeiten für interpretierte Sprachen gehört eine Version des AWS SDK. Lambda aktualisiert diese Laufzeiten regelmäßig, um die neueste SDK-Version zu verwenden. Die in Ihrer Laufzeit enthaltene SDK-Version finden Sie in den folgenden Abschnitten: + [In der Laufzeit enthaltene SDK-Versionen (Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [In der Laufzeit enthaltene SDK-Versionen (Python)](lambda-python.md#python-sdk-included) + [In der Laufzeit enthaltene SDK-Versionen (Ruby)](lambda-ruby.md#ruby-sdk-included) Um eine neuere Version des AWS SDK zu verwenden oder Ihre Funktionen an eine bestimmte Version zu binden, können Sie die Bibliothek mit Ihrem Funktionscode bündeln oder [eine Lambda-Schicht erstellen](chapter-layers.md). Weitere Informationen zum Erstellen eines Bereitstellungspakets mit Abhängigkeiten finden Sie in den folgenden Themen: ------ #### [ Node.js ] [Bereitstellen von Node.js Lambda-Funktionen mit ZIP-Dateiarchiven](nodejs-package.md) ------ #### [ Python ] [Arbeiten mit ZIP-Dateiarchiven und Python-Lambda-Funktionen](python-package.md) ------ #### [ Ruby ] [Bereitstellen von Ruby-Lambda-Funktionen mit ZIP-Dateiarchiven](ruby-package.md) ------ #### [ Java ] [Bereitstellen von Java-Lambda-Funktionen mit ZIP- oder JAR-Dateiarchiven](java-package.md) ------ #### [ Go ] [Bereitstellen von Lambda-Go-Funktionen mit ZIP-Dateiarchiven](golang-package.md) ------ #### [ C\$1 ] [Erstellen und Bereitstellen von C\$1-Lambda-Funktionen mit ZIP-Dateiarchiven](csharp-package.md) ------ #### [ PowerShell ] [PowerShell-Lambda-Funktionen mit .zip-Dateiarchiven bereitstellen](powershell-package.md) ------ ## Python: Bibliotheken werden falsch geladen **Problem:** (Python) *Einige Bibliotheken werden nicht korrekt aus dem Bereitstellungspaket geladen* Bibliotheken mit Erweiterungsmodulen, die in C oder C \$1\$1 geschrieben sind, müssen in einer Umgebung mit derselben Prozessorarchitektur wie Lambda (Amazon Linux) kompiliert werden. Weitere Informationen finden Sie unter [Arbeiten mit ZIP-Dateiarchiven und Python-Lambda-Funktionen](python-package.md). ## Java: Ihre Funktion braucht länger, um Ereignisse zu verarbeiten, nachdem sie von Java 11 auf Java 17 aktualisiert wurde **Problem:** (Java) *Ihre Funktion braucht länger, um Ereignisse zu verarbeiten, nachdem sie von Java 11 auf Java 17 aktualisiert wurde* Optimieren Sie Ihren Compiler mithilfe des `JAVA_TOOL_OPTIONS`-Parameters. Lambda-Laufzeiten für Java 17 und spätere Java-Versionen ändern die Standard-Compileroptionen. Die Änderung verbessert die Kaltstartzeiten für kurzlebige Funktionen, aber das bisherige Verhalten ist besser für rechenintensive, länger laufende Funktionen geeignet. Setzen Sie `JAVA_TOOL_OPTIONS` auf `-XX:-TieredCompilation`, um zum Verhalten von Java 11 zurückzukehren. Weitere Informationen zum Parameter `JAVA_TOOL_OPTIONS` erhalten Sie unter [Die `JAVA_TOOL_OPTIONS`-Umgebungsvariable verstehen](java-customization.md#java-tool-options). ## Kafka: Probleme bei der Fehlerbehandlung und beim erneuten Versuch der Konfiguration **Problem:** Bei der *Zuordnung von Kafka-Ereignisquellen können Einstellungen für Wiederholungsversuche oder Ziele für den Fall eines Fehlers nicht konfiguriert* werden Kafka-Wiederholungskonfigurationen und Ziele für den Fall eines Fehlers sind nur für Zuordnungen von Ereignisquellen verfügbar, bei denen der Bereitstellungsmodus aktiviert ist. Stellen Sie sicher, dass Sie Ihre Konfiguration vorgenommen haben, `ProvisionedPollerConfig` bevor Sie versuchen, `MinimumPollers` Wiederholungskonfigurationen festzulegen. Häufige Konfigurationsfehler: + **Unendliche Wiederholungen mit Bisect Batch** — Sie können die Option nicht aktivieren`BisectBatchOnFunctionError`, wenn die Option auf -1 (unendlich) gesetzt `MaximumRetryAttempts` ist. Legen Sie ein begrenztes Limit für Wiederholungsversuche fest oder deaktivieren Sie Bisect Batch. + **Rekursion zum selben Thema** — Das Kafka-Zielthema bei einem Fehler darf nicht mit einem Ihrer Quellthemen identisch sein. Wählen Sie einen anderen Themennamen für Ihr aktuelles Thema. + **Ungültiges Kafka-Zielformat** — Verwenden Sie das `kafka://` Format, wenn Sie ein Kafka-Thema als Ziel für den Fall eines Fehlers angeben. + **kafka: WriteData Berechtigungsprobleme** — Stellen Sie sicher, dass Ihre Ausführungsrolle über `kafka-cluster:WriteData` Berechtigungen für das Zielthema verfügt. Thema existiert nicht, Timeout-Ausnahmen oder Probleme mit der Schreib-API-Drosselung erfordern möglicherweise eine Erhöhung der Kontolimits. # Behebung von Problemen mit der Zuordnung von Ereignisquellen in Lambda Probleme in Lambda, die sich auf die [Zuordnung von Ereignisquellen](invocation-eventsourcemapping.md) beziehen, können komplexer sein, da sie das Debuggen mehrerer Services beinhalten. Darüber hinaus kann das Verhalten der Ereignisquelle je nach der verwendeten Ereignisquelle unterschiedlich sein. In diesem Abschnitt werden häufig auftretende Probleme im Zusammenhang mit der Zuordnung von Ereignisquellen aufgeführt und Hinweise zu deren Identifizierung und Behebung gegeben. **Anmerkung** In diesem Abschnitt wird zur Veranschaulichung eine Amazon-SQS-Ereignisquelle verwendet, aber die Prinzipien gelten auch für andere Zuordnungen von Ereignisquellen, die Nachrichten für Lambda-Funktionen in die Warteschlange stellen. ## Drosselung erkennen und verwalten In Lambda erfolgt die Drosselung, wenn das Gleichzeitigkeitslimit Ihrer Funktion oder Ihres Kontos erreicht ist. Betrachten Sie das folgende Beispiel, in dem es eine Lambda-Funktion gibt, um Nachrichten aus einer Amazon-SQS-Warteschlange zu lesen. Diese Lambda-Funktion simuliert 30-Sekunden-Aufrufe und hat eine Batchgröße von 1. Das bedeutet, dass die Funktion alle 30 Sekunden nur eine Nachricht verarbeitet: ``` const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms)) exports.handler = async (event) => { await doWork(30000) } ``` Bei einer so langen Aufrufzeit kommen Nachrichten schneller in der Warteschlange an als sie verarbeitet werden. Wenn die nicht reservierte Gleichzeitigkeit Ihres Kontos 100 beträgt, skaliert Lambda auf 100 gleichzeitige Ausführungen hoch, und dann erfolgt eine Drosselung. Sie können dieses Muster in den CloudWatch-Metriken für die Funktion sehen: ![\[Debugging-Operationen, Abbildung 10\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-10.png) Die CloudWatch-Metriken für die Funktion zeigen keine Fehler, aber das Diagramm **Gleichzeitige Ausführungen** zeigt, dass die maximale Gleichzeitigkeit von 100 erreicht ist. Aus diesem Grund zeigt das Diagramm **Drosselungen**, dass die Drosselung bereits besteht. Sie können Drosselungen mit CloudWatch-Alarmen erkennen und einen Alarm einstellen, sobald die Drosselungsmetrik für eine Funktion größer als 0 ist. Nachdem Sie das Drosselungsproblem identifiziert haben, stehen Ihnen einige Lösungsmöglichkeiten zur Verfügung: + Beantragen Sie eine Erhöhung der Gleichzeitigkeit von AWS-Support in dieser Region. + Identifizieren Sie Leistungsprobleme in der Funktion, um die Verarbeitungsgeschwindigkeit und damit den Durchsatz zu verbessern. + Erhöhen Sie die Batchgröße der Funktion, sodass bei jedem Aufruf mehr Nachrichten verarbeitet werden. ## Fehler in der Verarbeitungsfunktion Wenn die Verarbeitungsfunktion Fehler ausgibt, gibt Lambda die Nachrichten an die SQS-Warteschlange zurück. Lambda verhindert, dass Ihre Funktion skaliert wird, um Skalierungsfehler zu vermeiden. Die folgenden SQS-Metriken in CloudWatch weisen auf ein Problem mit der Warteschlangenverarbeitung hin: ![\[Debugging-Operationen, Abbildung 11\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-11.png) Insbesondere nehmen sowohl das Alter der ältesten Nachricht als auch die Anzahl der sichtbaren Nachrichten zu, während keine Nachrichten gelöscht werden. Die Warteschlange wächst weiter, aber Nachrichten werden nicht verarbeitet. Die CloudWatch-Metriken für die verarbeitende Lambda-Funktion zeigen ebenfalls, dass ein Problem vorliegt: ![\[Debugging-Operationen, Abbildung 12\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-12.png) Die Metrik für die **Anzahl der Fehler** ist ungleich Null und nimmt weiter zu, während die Anzahl der **gleichzeitigen Ausführungen** zurückgegangen ist und die Drosselung eingestellt wurde. Dies deutet darauf hin, dass Lambda die Hochskalierung Ihrer Funktion aufgrund von Fehlern eingestellt hat. Die CloudWatch Logs für die Funktion enthalten Details zur Art des Fehlers. Sie können dieses Problem lösen, indem Sie die Funktion identifizieren, die den Fehler verursacht hat und dann den Fehler finden und beheben. Nachdem Sie den Fehler behoben und den neuen Funktionscode bereitgestellt haben, sollten die CloudWatch-Metriken die Wiederherstellung der Verarbeitung zeigen: ![\[Debugging-Operationen, Abbildung 13\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/debugging-ops-figure-13.png) Hier sinkt die Metrik **Anzahl der Fehler** auf Null und die Metrik **Erfolgsquote** kehrt auf 100 % zurück. Lambda beginnt erneut mit der Hochskalierung der Funktion, wie im Diagramm **Gleichzeitige Ausführungen** dargestellt. ## Identifizierung und Behandlung von Gegendruck Wenn ein Ereignisproduzent konsistent Nachrichten für eine SQS-Warteschlange schneller generiert, als eine Lambda-Funktion diese verarbeiten kann, entsteht Gegendruck. In diesem Fall sollte die SQS-Überwachung das Alter der ältesten Nachricht linear ansteigen lassen, zusammen mit der ungefähren Anzahl der sichtbaren Nachrichten. Mithilfe von CloudWatch-Alarmen können Sie Gegendruck in Warteschlangen erkennen. Die Schritte zur Behebung von Gegendruck hängen von Ihrem Workload ab. Wenn das Hauptziel darin besteht, die Verarbeitungskapazität und den Durchsatz durch die Lambda-Funktion zu erhöhen, haben Sie einige Möglichkeiten: + Beantragen Sie bei AWS-Support eine Erhöhung der Gleichzeitigkeit in der betreffenden Region. + Erhöhen Sie die Batchgröße der Funktion, sodass bei jedem Aufruf mehr Nachrichten verarbeitet werden. # Beheben von Netzwerkproblemen in Lambda Standardmäßig führt Lambda Ihre Funktionen in einer internen Virtual Private Cloud (VPC) mit Konnektivität zu AWS -Services und dem Internet aus. Um auf lokale Netzwerkressourcen zuzugreifen, können Sie [Ihre Funktion so konfigurieren, dass sie sich mit einer VPC in Ihrem Konto verbindet](configuration-vpc.md). Wenn Sie dieses Feature verwenden, verwalten Sie den Internetzugriff und die Netzwerkkonnektivität der Funktion mit Ressourcen von Amazon Virtual Private Cloud (Amazon VPC). Netzwerkverbindungsfehler können auf Probleme mit der Routing-Konfiguration Ihrer VPC, den Sicherheitsgruppenregeln, AWS Identity and Access Management (IAM) -Rollenberechtigungen oder der Network Address Translation (NAT) oder auf die Verfügbarkeit von Ressourcen wie IP-Adressen oder Netzwerkschnittstellen zurückzuführen sein. Je nach Problem wird möglicherweise ein bestimmter Fehler oder Timeout angezeigt, wenn eine Anfrage ihr Ziel nicht erreichen kann. **Topics** + [VPC: Funktion verliert Internetzugriff oder läuft ab](#troubleshooting-networking-cfn) + [VPC: TCP- oder UDP-Verbindung bricht zeitweise ab](#troubleshooting-networking-tcp-udp) + [VPC: Die Funktion benötigt Zugriff, AWS-Services ohne das Internet zu nutzen](#troubleshooting-networking-access) + [VPC: Grenzwert für Elastic-Network-Schnittstellen erreicht](#troubleshooting-networking-limit) + [EC2: Elastische Netzwerkschnittstelle mit dem Typ „Lambda“](#troubleshooting-networking-eni) + [DNS: Verbindung zu Hosts mit UNKNOWNHOSTEXCEPTION schlägt fehl](#troubleshooting-networking-dns-tcp) ## VPC: Funktion verliert Internetzugriff oder läuft ab **Problem:** *Ihre Lambda-Funktion verliert Internetzugriff nach der Verbindung mit einer VPC.* **Fehler:** *Fehler: Verbindung ETIMEDOUT 176.32.98.189:443* **Fehler:** *Fehler: Zeitüberschreitung der Aufgabe nach 10,00 Sekunden* **FehlerReadTimeoutError:** *Timeout beim Lesen. (Timeout beim Lesen = 15*) Wenn Sie eine Funktion mit einer VPC verbinden, werden alle ausgehenden Anforderungen über die VPC geleitet. Um eine Verbindung zum Internet herzustellen, konfigurieren Sie Ihre VPC so, dass ausgehender Datenverkehr aus dem Subnetz der Funktion an ein NAT-Gateway in einem öffentlichen Subnetz gesendet wird. Weitere Informationen und VPC-Beispielkonfigurationen finden Sie unter [Aktivieren Sie den Internetzugang für VPC-verbundene Lambda-Funktionen](configuration-vpc-internet.md). Wenn einige Ihrer TCP-Verbindungen ein Timeout aufweisen, überprüfen Sie [VPC: TCP- oder UDP-Verbindung bricht zeitweise ab](#troubleshooting-networking-tcp-udp), ob Ihr Subnetz eine Netzwerkzugriffskontrollliste (NACL) verwendet. Andernfalls liegt dies wahrscheinlich an einer Paketfragmentierung. Lambda-Funktionen können eingehende fragmentierte TCP-Anfragen nicht verarbeiten, da Lambda keine IP-Fragmentierung für TCP oder ICMP unterstützt. ## VPC: TCP- oder UDP-Verbindung bricht zeitweise ab **Anmerkung** Dieses Problem tritt nur auf, wenn Ihr Subnetz eine [Zugriffssteuerungsliste (ACL)](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics) für Netzwerke verwendet. Für Lambda ist kein Netzwerk ACLs erforderlich, um eine Verbindung zu Ihren Subnetzen herzustellen. **Problem:** *Lambda verliert zeitweise die Verbindung zu Ihren VPC-Subnetzen, für die Sie eine Netzwerk-Zugriffssteuerungsliste (ACL) konfiguriert haben.* Für VPC-fähige Lambda-Funktionen AWS erstellt es eine [Hyperplane ENIs](configuration-vpc.md#configuration-vpc-enis) im Kundenkonto und verwendet kurzlebige Ports, um Lambda mit der VPC des Kunden `1024` `65535` zu verbinden. Wenn Sie das Netzwerk ACLs im Zielsubnetz verwenden, müssen Sie den Portbereich sowohl für TCP als auch für UDP zulassen. `1024` `65535` Wenn dieser vollständige Portbereich nicht zugelassen wird, kann es zu zeitweiligen Verbindungsausfällen kommen. ## VPC: Die Funktion benötigt Zugriff, AWS-Services ohne das Internet zu nutzen **Problem:** *Ihre Lambda-Funktion benötigt Zugriff auf, AWS-Services ohne das Internet zu verwenden*. Verwenden Sie VPC-Endpunkte, um eine Funktion AWS-Services von einem privaten Subnetz ohne Internetzugang aus zu verbinden. ## VPC: Grenzwert für Elastic-Network-Schnittstellen erreicht **Fehler ENILimitReachedException:** *Das elastic network interface Network-Schnittstellenlimit wurde für die VPC der Funktion erreicht*. Wenn Sie eine Funktion mit einer Lambda-VPC verbinden, erstellt Lambda für jede Kombination aus Subnetz und Sicherheitsgruppe, die der Funktion zugeordnet ist, eine Elastic-Network-Schnittstelle. Das Standard-Servicekontingent beträgt 250 Netzwerkschnittstellen pro VPC. Zum Anfordern einer Erhöhung für ein Kontingent können Sie die [Service-Quotas-Konsole](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26) verwenden. ## EC2: Elastische Netzwerkschnittstelle mit dem Typ „Lambda“ **Fehlercode:** *Client. OperationNotPermitted* **Fehlermeldung:** *Die Sicherheitsgruppe kann für diesen Schnittstellentyp nicht geändert werden* Sie erhalten diesen Fehler, wenn Sie versuchen, eine Elastic-Network-Schnittstelle (ENI) zu ändern, das von Lambda verwaltet wird. Das `ModifyNetworkInterfaceAttribute` ist nicht in der Lambda-API für Aktualisierungsvorgänge auf elastischen Netzwerkschnittstellen enthalten, die von Lambda erstellt wurden. ## DNS: Verbindung zu Hosts mit UNKNOWNHOSTEXCEPTION schlägt fehl **Fehlermeldung:** *UNKNOWNHOSTEXCEPTION* Lambda-Funktionen unterstützen maximal 20 gleichzeitige TCP-Verbindungen für die DNS-Auflösung. Ihre Funktion hat möglicherweise dieses Limit ausgeschöpft. Die meisten DNS-Anfragen werden über UDP gestellt. Wenn Ihre Funktion nur UDP-DNS-Verbindungen herstellt, ist es unwahrscheinlich, dass dies Ihr Problem ist. Bevor Sie also Ihren DNS-Verkehr eingehend untersuchen, vergewissern Sie sich, dass Ihre DNS-Infrastruktur ordnungsgemäß konfiguriert und in Ordnung ist und dass sich Ihre Lambda-Funktion auf einen in DNS angegebenen Host bezieht. Wenn Sie Ihr Problem im Zusammenhang mit der maximalen TCP-Verbindung diagnostizieren, beachten Sie, dass Sie keine Erhöhung dieses Limits beantragen können. Wenn Ihre Lambda-Funktion aufgrund großer DNS-Payloads auf TCP DNS zurückgreift, überprüfen Sie, ob Ihre Lösung Bibliotheken verwendet, die EDNS unterstützen. Weitere Informationen über EDNS finden Sie in der [Norm RFC 6891](https://datatracker.ietf.org/doc/html/rfc6891). Wenn Ihre DNS-Nutzdaten die EDNS-Maximalgröße ständig überschreiten, kann Ihre Lösung das TCP DNS-Limit dennoch ausschöpfen.