Debugging von AWS Lambda: Häufige Aufruffehler und deren Behebung

AWS Lambda-Aufruffehler treten in der Regel aus einem von drei Gründen auf: Der Aufrufer kann die Funktion nicht aufrufen, Lambda kann die Laufzeit nicht starten oder Ihr Code startet und schlägt dann fehl. Der schnellste Weg zur Behebung besteht darin, zu identifizieren, welche Phase fehlgeschlagen ist, bevor Sie Speicher, Timeout, IAM-Richtlinien oder VPC-Einstellungen ändern.

Beginnen Sie mit CloudWatch-Protokollen, überprüfen Sie dann nacheinander Berechtigungen, Handler-Einstellungen, Abhängigkeiten und Netzwerke.

Festlegen der Debugging-Basislinie: CloudWatch-Protokolle

Bevor Sie die Funktion ändern, überprüfen Sie die Protokollgruppe /aws/lambda/YourFunctionName. Eine normale Lambda-Ausführung enthält normalerweise diese Plattform-Protokollzeilen:

1. START: Zeigt den Beginn der Ausführung an.
2. END: Zeigt den Abschluss der Ausführung an.
3. REPORT: Stellt zusammenfassende Metriken bereit (Dauer, abgerechnete Dauer, verwendeter Speicher, maximal verwendeter Speicher und X-Ray-Tracing-Details).

Wenn die Funktion nie startet, werden möglicherweise keine Anwendungsprotokolle angezeigt. Überprüfen Sie in diesem Fall den aufrufenden Dienst, das Lambda-Konsolentestergebnis, CloudTrail-Ereignisse und die ressourcenbasierte Richtlinie der Funktion.

Behebung von Berechtigungs- und Zugriffsfehlern

Berechtigungsfehler sind wohl die häufigste Ursache für fehlgeschlagene Lambda-Aufrufe. Diese fallen typischerweise in zwei Kategorien: Der Funktion fehlt die Berechtigung zum Ausführen, oder der aufrufenden Entität fehlt die Berechtigung zum Aufrufen der Funktion.

Fehler bei der Ausführungsrolle (IAM-Rolle)

Jede Lambda-Funktion muss eine IAM-Ausführungsrolle übernehmen. Wenn diese Rolle falsch konfiguriert ist, kann die Funktion nicht mit den erforderlichen AWS-Diensten interagieren.

Häufig fehlende Berechtigungen:

Benötigter Dienstzugriff	Erforderliche IAM-Richtlinienaktionen
Protokollierung in CloudWatch	logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents
VPC-Konnektivität	ec2:CreateNetworkInterface, ec2:DeleteNetworkInterface, ec2:DescribeNetworkInterfaces
Lesen von S3/DynamoDB	s3:GetObject, dynamodb:GetItem, etc.

Behebung:

1. Navigieren Sie in der AWS-Konsole zur Konfiguration der Lambda-Funktion.
2. Überprüfen Sie den Tab "Berechtigungen" und sehen Sie sich die angehängte IAM-Rollenrichtlinie an.
3. Stellen Sie sicher, dass die Rolle über die grundlegende AWS-verwaltete Richtlinie AWSLambdaBasicExecutionRole verfügt oder dass ihre benutzerdefinierte Richtlinie die erforderlichen CloudWatch-Aktionen enthält.
4. Fügen Sie nur die Dienstberechtigungen hinzu, die Ihr Code tatsächlich benötigt, wie z. B. s3:GetObject für ein bestimmtes Bucket-Präfix.

Fehler bei ressourcenbasierten Richtlinien (Aufrufberechtigungen)

Wenn Ihre Lambda-Funktion von einem anderen Dienst (wie S3, API Gateway, SNS oder einem kontenübergreifenden Aufruf) aufgerufen wird, benötigt dieser Dienst eine explizite Berechtigung zum Aufrufen Ihrer Funktion.

Symptom: Der Dienst (z. B. S3) versucht, die Lambda-Funktion auszulösen, aber in den CloudWatch-Protokollen erscheint nichts, und der Dienst meldet einen Fehler.

Behebung: Verwenden Sie den CLI-Befehl add-permission oder die entsprechende Konsoleneinstellung, um Aufrufrechte zu gewähren. Zum Beispiel, um einem S3-Bucket das Aufrufen der Funktion zu erlauben:

aws lambda add-permission \
    --function-name my-processing-function \
    --statement-id S3InvokePermission \
    --action lambda:InvokeFunction \
    --principal s3.amazonaws.com \
    --source-arn arn:aws:s3:::my-trigger-bucket

Überprüfen Sie bei kontenübergreifenden Aufrufen beide Seiten: Der Aufrufer benötigt eine IAM-Berechtigung zum Aufrufen von lambda:InvokeFunction, und die Lambda-Funktion benötigt eine ressourcenbasierte Richtlinie, die diesen Aufrufer zulässt.

Konfigurations- und Ressourcenbeschränkungsfehler

Diese Fehler beziehen sich auf die definierten Laufzeitumgebungseinstellungen und Ressourcenbeschränkungen, die der Funktion auferlegt werden.

Fehler aufgrund von Funktionszeitüberschreitungen

Eine Funktionszeitüberschreitung ist ein häufiger Fehler, der darauf hinweist, dass die Ausführung die maximal zugewiesene Zeit überschritten hat. Lambda beendet die Ausführung zwangsweise und protokolliert einen Fehler vom Typ Task timed out.

Diagnose:

1. Überprüfen Sie die REPORT-Zeile in den CloudWatch-Protokollen. Vergleichen Sie die Duration mit dem konfigurierten Timeout.
2. Wenn die Funktion frühzeitig ein Timeout hat (z. B. nach 5 Sekunden bei einem 30-Sekunden-Limit), liegt der Engpass wahrscheinlich bei der Initialisierung oder Konnektivität (z. B. Warten auf eine DNS-Auflösung).

Behebungen:

• Timeout erhöhen: Wenn die Aufgabe von Natur aus langläuft (z. B. große Datenverarbeitung), erhöhen Sie das Timeout (bis zu 15 Minuten).
• Code/Abhängigkeiten optimieren: Wenn die Aufgabe langsam ist, profilieren Sie den Code, um Engpässe zu identifizieren. Stellen Sie sicher, dass alle externen Aufrufe innerhalb des Codes angemessene Timeouts definiert haben.
• Cold Starts handhaben: Große Initialisierungsprozesse können zu Zeitüberschreitungen beitragen. Verwenden Sie Lambda Provisioned Concurrency, wenn Cold Starts kritisch sind.

Fehler aufgrund von Speichererschöpfung

Wenn Ihre Funktion mehr RAM benötigt als zugewiesen, stürzt sie ab und protokolliert je nach Laufzeit einen OutOfMemoryError oder eine ähnliche Meldung.

Diagnose: Überprüfen Sie die Metrik Max Memory Used in der CloudWatch REPORT-Zeile. Wenn dieser Wert konstant nahe oder gleich der konfigurierten Memory Size ist, liegt möglicherweise ein Speicherleck oder unzureichende Ressourcen vor.

Behebung: Erhöhen Sie die Speicherzuweisung und testen Sie erneut. Lambda weist mehr CPU zu, je mehr Speicher Sie zuweisen, sodass ein höherer Speicher manchmal die Dauer ausreichend verkürzen kann, um einen Teil der Kosten auszugleichen. Messen Sie Ihre eigene Funktion, anstatt anzunehmen, dass sie günstiger sein wird.

AWS Lambda Power Tuning kann helfen, Speichereinstellungen für eine bestimmte Arbeitslast zu vergleichen.

Handler-Fehlkonfiguration (Runtime.HandlerNotFound)

Dies tritt auf, wenn Lambda den in der Funktionskonfiguration definierten Einstiegspunkt nicht finden kann.

Symptom: Error: Runtime.HandlerNotFound oder ähnlicher Startfehler.

Behebung: Überprüfen Sie, ob das Handler-Feld in den Funktionseinstellungen der Struktur [Dateiname].[Funktionsname] entspricht. Beispielsweise muss für eine Python-Funktion, die in my_code.py mit der Einstiegsfunktion lambda_handler definiert ist, der Handler auf my_code.lambda_handler gesetzt sein.

Für Node.js folgen Handler-Namen dem Modul und der exportierten Funktion, z. B. index.handler für eine exportierte handler-Funktion in index.js.

Netzwerk- und VPC-Konnektivitätsprobleme

Wenn eine Lambda-Funktion so konfiguriert ist, dass sie in einer Virtual Private Cloud (VPC) ausgeführt wird, erhält sie Zugriff auf private Ressourcen, verliert aber standardmäßig den Zugriff auf das öffentliche Internet.

Fehlender Internetzugriff

Wenn sich Ihre Lambda-Funktion in einer VPC befindet und eine Verbindung zu externen Diensten herstellen muss, benötigt sie eine Route zum Internet über ein NAT-Gateway oder einen anderen genehmigten Ausgangspfad. Das Platzieren der Funktion in einem öffentlichen Subnetz gibt ihr keine öffentliche IP-Adresse.

Symptom: HTTP-Verbindungsfehler, Zeitüberschreitungen beim Zugriff auf öffentliche Endpunkte.

Behebungen:

1. Stellen Sie sicher, dass die Funktion an private Subnetze angehängt ist, die für Lambda-Workloads vorgesehen sind.
2. Stellen Sie sicher, dass diese privaten Subnetze einen Routentabelleneintrag haben, der den ausgehenden Internetverkehr (0.0.0.0/0) an ein NAT-Gateway weiterleitet.
3. Wenn die Lambda-Funktion nur privat auf AWS-Dienste zugreifen muss, ziehen Sie VPC-Endpunkte in Betracht, wie Gateway-Endpunkte für S3 und DynamoDB oder Schnittstellenendpunkte für unterstützte Dienste.

Einschränkungen durch Sicherheitsgruppen und ACLs

Ihre Funktion kann erfolgreich starten, aber hängen bleiben, wenn ihre Sicherheitsgruppe, die Ziel-Sicherheitsgruppe, die Netzwerk-ACL oder die Routingtabelle die Verbindung blockiert.

Behebung: Erlauben Sie ausgehenden Datenverkehr von der Lambda-Sicherheitsgruppe zum Zielport und erlauben Sie eingehenden Datenverkehr auf der Ziel-Sicherheitsgruppe von der Lambda-Sicherheitsgruppe. Beispielsweise benötigt eine Lambda-Funktion, die eine Verbindung zu PostgreSQL herstellt, ausgehendes TCP 5432 von Lambda und eingehendes TCP 5432 auf der Datenbankseite.

Wenn der Ausführungsrolle die erforderlichen EC2-Netzwerkschnittstellenberechtigungen für den VPC-Zugriff fehlen, kann Lambda bei der Vorbereitung der VPC-Netzwerke, die zum Ausführen der Funktion erforderlich sind, fehlschlagen.

Bereitstellungs- und Laufzeitfehlkonfigurationen

Diese Probleme beziehen sich darauf, wie das Codebundle strukturiert ist oder welche Laufzeitumgebung gewählt wurde.

Fehler bei Abhängigkeiten und Paketen

Wenn Ihr Code auf externe Bibliotheken angewiesen ist, die nicht korrekt gebündelt oder für die spezifische Laufzeitumgebung installiert wurden, schlägt die Funktion während der Initialisierung fehl.

Symptom: Laufzeitausnahmen wie module not found, cannot import name oder No such file or directory (besonders häufig bei Python oder Node.js).

Behebungen:

1. Lokale vs. Lambda-Umgebung: Stellen Sie sicher, dass Sie Abhängigkeiten in einer Umgebung erstellen, die der Lambda-Laufzeit entspricht (z. B. verwenden Sie pip install -t . für Python, um Abhängigkeiten korrekt zu platzieren).
2. Lambda Layers verwenden: Packen Sie größere, stabile Abhängigkeiten in Lambda Layers, um die Größe des Hauptbereitstellungspakets zu reduzieren und die Bereitstellungsgeschwindigkeit zu verbessern.
3. Pfad überprüfen: Stellen Sie sicher, dass Ihre Laufzeitkonfiguration korrekt auf den Speicherort der installierten Abhängigkeiten verweist.

Größe und Format des Bereitstellungspakets

Lambda hat Grenzen für die Größe des Bereitstellungspakets, und diese Grenzen unterscheiden sich je nachdem, ob Sie eine .zip-Datei direkt hochladen, über Amazon S3 hochladen, Layers verwenden oder ein Container-Image bereitstellen. Überprüfen Sie die aktuellen Lambda-Kontingente für Ihre Verpackungsmethode, bevor Sie eine große Funktion umstrukturieren.

Symptom: Die Bereitstellung schlägt mit einem Größenfehler fehl, oder ein großes Paket trägt zu langsameren Cold Starts bei.

Behebungen:

• Beschneiden: Entfernen Sie unnötige Dateien, Dokumentation und Entwicklungsabhängigkeiten.
• Layers: Verschieben Sie statische Assets oder große Abhängigkeiten in Lambda Layers.
• Container-Images: Erwägen Sie für sehr große Anwendungen, die Funktion als Container-Image von Amazon ECR bereitzustellen.

Ereignis- und Nutzlastprobleme

Einige Aufruffehler resultieren aus dem Ereignis selbst:

• Fehlerhaftes JSON: Konsolentests und CLI-Aufrufe erfordern gültige JSON-Nutzlasten.
• Unerwartete Ereignisform: Ein S3-Ereignis, API Gateway-Ereignis und EventBridge-Ereignis haben nicht dieselben Felder.
• Asynchrones Wiederholungsverhalten: Asynchrone Aufrufe können nach Fehlern wiederholt werden und fehlgeschlagene Ereignisse an ein Ziel oder eine Dead-Letter-Queue senden, falls konfiguriert.

Führen Sie für einen direkten CLI-Test die Antwort und Protokolle ab:

aws lambda invoke \
    --function-name my-function \
    --payload '{"ping": true}' \
    --cli-binary-format raw-in-base64-out \
    response.json

Die Option --cli-binary-format raw-in-base64-out wird bei AWS CLI v2 häufig benötigt, wenn rohes JSON direkt in der Befehlszeile übergeben wird.

Zusammenfassung der Fehlerbehebungsschritte

Wenn Sie auf einen Aufruffehler stoßen, befolgen Sie diesen systematischen Ansatz:

1. CloudWatch zuerst prüfen: Suchen Sie nach sofortigen Fehlern, die vom Lambda-Dienst vor der START-Zeile protokolliert wurden.
2. IAM-Rolle überprüfen: Stellen Sie sicher, dass die Ausführungsrolle der Funktion alle erforderlichen Berechtigungen hat (Protokollierung, VPC und Dienstzugriff).
3. Konfiguration überprüfen: Überprüfen Sie den Handler-Namen, die Speichereinstellung und das Timeout-Limit.
4. VPC-Einstellungen analysieren: Wenn Sie eine VPC verwenden, überprüfen Sie die Sicherheitsgruppen, Subnetzzuordnungen und Routentabellen (insbesondere für den NAT-Gateway-Zugriff).
5. Abhängigkeiten untersuchen: Bestätigen Sie, dass alle erforderlichen Bibliotheken korrekt verpackt und für die Laufzeit zugänglich sind.

Sobald Sie wissen, ob der Fehler vor dem Aufruf, während des Laufzeitstarts oder in Ihrem Code aufgetreten ist, wird die Behebung viel gezielter. Überprüfen Sie zuerst die Protokolle, weisen Sie die aktive IAM-Identität und Ressourcenrichtlinie nach, und passen Sie dann Handler, Paket, Timeout, Speicher und VPC-Einstellungen basierend auf dem spezifischen Fehler an, den Sie sehen.