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.
# Lambda-Laufzeiten
Lambda unterstützt mehrere Sprachen durch die Verwendung von *Laufzeiten*. Eine Laufzeit bietet eine sprachspezifische Umgebung, die Aufrufereignisse, Kontextinformationen und Antworten zwischen Lambda und der Funktion weiterleitet. Sie können von Lambda bereitgestellte Laufzeiten verwenden oder Ihre eigenen erstellen.
Lambda ist unabhängig von Ihrer Wahl der Laufzeit. Für einfache Funktionen bieten interpretierte Sprachen wie Python und Node.js die schnellste Leistung. Bei Funktionen mit komplexeren Berechnungen lassen sich kompilierte Sprachen wie Java oft langsamer initialisieren, werden aber im Lambda-Handler schnell ausgeführt. Die Wahl der Laufzeit hängt auch von der Präferenz der Entwickler und der Vertrautheit mit der Sprache ab.
Jede größere Programmiersprachenversion verfügt über eine separate Laufzeit mit einer eindeutigen *Laufzeitkennung*, z. B. `nodejs24.x` oder `python3.14`. Um eine Funktion für die Verwendung einer neuen Hauptsprachversion zu konfigurieren, müssen Sie die Laufzeitkennung ändern. Da die Abwärtskompatibilität zwischen Hauptversionen AWS Lambda nicht garantiert werden kann, handelt es sich um einen kundenorientierten Vorgang.
Bei einer [Funktion, die als Container-Image definiert ist](images-create.md), wählen Sie beim Erstellen des Container-Images eine Laufzeit und die Linux-Distribution aus. Um die Laufzeit zu ändern, erstellen Sie ein neues Container-Image.
Wenn Sie ein ZIP-Dateiarchiv für das Bereitstellungspaket verwenden, wählen Sie beim Erstellen der Funktion eine Laufzeit aus. Um die Laufzeit zu ändern, können Sie die [Konfiguration Ihrer Funktion aktualisieren](configuration-function-zip.md). Die Laufzeit ist mit einer der Amazon Linux-Distributionen gepaart. Die zugrunde liegende Ausführungsumgebung bietet zusätzliche Bibliotheken und [Umgebungsvariablen](configuration-envvars.md), auf die Sie über Ihren Funktionscode zugreifen können.
Lambda ruft Ihre Funktion in einer [Ausführungsumgebung](lambda-runtime-environment.md) auf. Die Ausführungsumgebung bietet eine sichere und isolierte Laufzeitumgebung, die die zum Ausführen Ihrer Funktion erforderlichen Ressourcen verwaltet. Lambda verwendet die Ausführungsumgebung eines vorherigen Aufrufs wieder, sofern vorhanden, oder kann eine neue Ausführungsumgebung erstellen.
Um andere Sprachen in Lambda zu verwenden, wie [Go](lambda-golang.md) oder [Rust](lambda-rust.md), verwenden Sie eine [reine OS-Laufzeit](runtimes-provided.md). Die Lambda-Ausführungsumgebung bietet eine [Laufzeitschnittstelle](runtimes-api.md) zum Abrufen von Aufrufereignissen und Senden von Antworten. Sie können andere Sprachen bereitstellen, indem Sie zusammen mit Ihrem Funktionscode oder in einem [Layer](chapter-layers.md) eine [benutzerdefinierte Laufzeit](runtimes-custom.md) implementieren.
## Unterstützte Laufzeiten
In der folgenden Tabelle sind die unterstützten Lambda-Laufzeiten und ihre voraussichtlichen Ablauftermine aufgeführt. Wenn eine Laufzeit als veraltet gilt, können Sie für einen begrenzten Zeitraum weiterhin Funktionen erstellen und aktualisieren. Weitere Informationen finden Sie unter [Unterstützung der Verwendung nach der Einstellung](#runtime-deprecation-levels). Die Tabelle enthält die aktuell angenommenen Ablaufdaten für die Laufzeit, basierend auf unserer [Richtlinie für den Laufzeitablauf](#runtime-support-policy). Diese Daten dienen zu Planungszwecken und können sich ändern.
**Wichtig**
Das Ende der Lebensdauer von Amazon Linux 2 ist für den 30. Juni 2026 geplant. Lambda-Laufzeiten und Container-Basis-Images für Java 8 (AL2), Java 11, Java 17, Python 3.10, Python 3.11 und provided.al2 erhalten bis zu den in der Tabelle unten aufgeführten Verfallsdaten weiterhin Patches für [kritische und ausgewählte wichtige](https://alas.aws.amazon.com/faqs.html) Amazon Linux 2-Sicherheitsprobleme sowie Sprach-Runtime-Patches.
Wir empfehlen Kunden, so bald wie möglich ein Upgrade auf eine Amazon Linux 2023-basierte Runtime durchzuführen. Kunden, die auf Java 21 oder Java 25 aktualisieren, können [AWS Transform Custom](https://docs.aws.amazon.com/transform/latest/userguide/custom.html) verwenden, um sie bei diesen Upgrades zu unterstützen. Für Kunden, die ihre Java-Version nicht aktualisieren können, planen wir, Amazon Linux 2023-basierte Laufzeiten für Java 8, Java 11 und Java 17 vor Ende des zweiten Quartals 2026 zu veröffentlichen.
| Name | ID | Betriebssystem | Datum der Veraltung | Blockfunktion erstellen | Blockfunktion aktualisieren |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 30. April 2028 | 1. Juni 2028 | 1. Juli 2028 |
| Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 30. April 2027 | 1. Juni 2027 | 1. Juli 2027 |
| Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 30. April 2026 | 31. August 2026 | 30. September 2026 |
| Python 3.14 | `python3.14` | Amazon Linux 2023 | 30. Juni 2029 | 31. Juli 2029 | 31. August 2029 |
| Python 3.13 | `python3.13` | Amazon Linux 2023 | 30. Juni 2029 | 31. Juli 2029 | 31. August 2029 |
| Python 3.12 | `python3.12` | Amazon Linux 2023 | 31. Oktober 2028 | 30. November 2028 | 10. Januar 2029 |
| Python 3.11 | `python3.11` | Amazon Linux 2 | 30. Juni 2027 | 31. Juli 2027 | 31. August 2027 |
| Python 3.10 | `python3.10` | Amazon Linux 2 | 31. Oktober 2026 | 30. November 2026 | 15. Januar 2027 |
| Java 25 | `java25` | Amazon Linux 2023 | 30. Juni 2029 | 31. Juli 2029 | 31. August 2029 |
| Java 21 | `java21` | Amazon Linux 2023 | 30. Juni 2029 | 31. Juli 2029 | 31. August 2029 |
| Java 17 | `java17` | Amazon Linux 2 | 30. Juni 2027 | 31. Juli 2027 | 31. August 2027 |
| Java 11 | `java11` | Amazon Linux 2 | 30. Juni 2027 | 31. Juli 2027 | 31. August 2027 |
| Java 8 | `java8.al2` | Amazon Linux 2 | 30. Juni 2027 | 31. Juli 2027 | 31. August 2027 |
| .NET 10 | `dotnet10` | Amazon Linux 2023 | 14. November 2028 | 14. Dezember 2028 | 15. Januar 2029 |
| .NET 9 (nur Container) | `dotnet9` | Amazon Linux 2023 | 10. November 2026 | Nicht geplant | Nicht geplant |
| .NET 8 | `dotnet8` | Amazon Linux 2023 | 10. November 2026 | 10. Dezember 2026 | 11. Januar 2027 |
| Rubin 3.4 | `ruby3.4` | Amazon Linux 2023 | 31. März 2028 | 30. April 2028 | 31. Mai 2028 |
| Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 31. März 2027 | 30. April 2027 | 31. Mai 2027 |
| Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 31. März 2026 | 31. August 2026 | 30. September 2026 |
| Reine OS-Laufzeit | `provided.al2023` | Amazon Linux 2023 | 30. Juni 2029 | 31. Juli 2029 | 31. August 2029 |
| Reine OS-Laufzeit | `provided.al2` | Amazon Linux 2 | 31. Juli 2026 | 31. August 2026 | 30. September 2026 |
**Anmerkung**
Für neue Regionen wird Lambda keine Laufzeiten unterstützen, die innerhalb der nächsten sechs Monate veraltet sein werden.
Lambda hält verwaltete Laufzeiten und ihre entsprechenden Container-Basis-Images mit Patches und Unterstützung für kleinere Versionen auf dem neuesten Stand. Weitere Informationen finden Sie unter [Lambda-Laufzeitaktualisierungen](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html).
Um programmgesteuert mit anderen AWS-Services und Ressourcen aus Ihrer Lambda-Funktion zu interagieren, können Sie eine von verwenden. AWS SDKs Die Laufzeiten Node.js, Python und Ruby enthalten eine Version des AWS SDK. Um jedoch die volle Kontrolle über Ihre Abhängigkeiten zu behalten und die [Abwärtskompatibilität](runtimes-update.md#runtime-update-compatibility) bei automatischen Laufzeitaktualisierungen zu maximieren, empfehlen wir Ihnen, die von Ihrem Code verwendeten SDK-Module (zusammen mit allen Abhängigkeiten) immer in das Bereitstellungspaket Ihrer Funktion oder in eine [Lambda-Ebene](chapter-layers.md) aufzunehmen.
Wir empfehlen, die in der Laufzeit enthaltene SDK-Version nur zu verwenden, wenn Sie keine zusätzlichen Pakete in Ihre Bereitstellung aufnehmen können. Zum Beispiel, wenn Sie Ihre Funktion mit dem Code-Editor der Lambda-Konsole oder mit Inline-Funktionscode in einer CloudFormation Vorlage erstellen.
Lambda aktualisiert regelmäßig die Versionen der in den Laufzeiten Node.js, Python und Ruby AWS SDKs enthaltenen. Informationen darüber, welche Version des AWS -SDKs in der von Ihnen verwendeten Laufzeit enthalten ist, 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)
Lambda unterstützt weiterhin die Programmiersprache Go, auch nachdem die Go 1.x-Laufzeit veraltet ist. *Weitere Informationen finden Sie im Compute-Blog unter [AWS Lambda Funktionen von der GO1.x-Laufzeit zur benutzerdefinierten Laufzeit auf Amazon Linux 2 migrieren](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/).AWS *
Alle unterstützten Lambda-Laufzeiten unterstützen sowohl x86\$164- als auch arm64-Architekturen.
## Neue Laufzeit-Versionen
Lambda stellt verwaltete Laufzeiten für neue Sprachversionen nur dann zur Verfügung, wenn die Version die LTS-Phase (Long-Term Support) des Veröffentlichungszyklus der Sprache erreicht. Zum Beispiel für den [Node.js-Veröffentlichungszyklus](https://nodejs.org/en/about/previous-releases), wenn die Version die Active LTS-Phase erreicht.
Bevor die Version die LTS-Phase erreicht, befindet sie sich noch in der Entwicklung und kann noch grundlegenden Änderungen unterliegen. Lambda wendet Laufzeit-Updates standardmäßig automatisch an. Wenn Sie also Änderungen an einer Laufzeitversion vornehmen, funktionieren Ihre Funktionen möglicherweise nicht mehr wie erwartet.
Lambda bietet keine verwalteten Laufzeiten für Sprachversionen, die nicht für die LTS-Veröffentlichung geplant sind.
Im Folgenden ist der geplante Startmonat für die kommenden Lambda-Laufzeiten aufgeführt. Diese Termine sind nur Richtwerte und können sich ändern.
+ **Ruby 3.5** — März 2026
+ **Java 8, 11 und 17 auf AL2 023** - Q2 2026
+ **Node.js 26 — November 2026**
+ **Python 3.15** - November 2026
## Richtlinie für den Laufzeitablauf
Lambda-Laufzeiten für ZIP-Dateiarchive werden um eine Kombination aus Betriebssystem, Programmiersprache und Softwarebibliotheken aufgebaut, die Wartungen und Sicherheitsupdates erfordern. Die Standard-Einstellungsrichtlinie von Lambda sieht vor, dass eine Laufzeit als veraltet eingestuft wird, wenn für eine wichtige Komponente der Laufzeit die langfristige Unterstützung (LTS) durch die Community ausläuft und keine Sicherheitsupdates mehr verfügbar sind. In den meisten Fällen handelt es sich dabei um die Sprachlaufzeit. In einigen Fällen kann eine Laufzeit jedoch als veraltet gelten, weil das Betriebssystem das LTS-Ende erreicht.
Wenn eine Runtime als veraltet gilt, AWS darf sie keine Sicherheitspatches oder Updates mehr auf diese Runtime anwenden, und Funktionen, die diese Runtime verwenden, haben keinen Anspruch mehr auf technischen Support. Solche veralteten Laufzeiten werden „wie sie sind“ ohne jegliche Garantie bereitgestellt und können Bugs, Fehler, Defekte oder andere Schwachstellen enthalten.
*Weitere Informationen zur Verwaltung von Runtime-Upgrades und veralteten Versionen finden Sie in den folgenden Abschnitten und unter [AWS Lambda Runtime-Upgrades verwalten](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/) im Compute-Blog.AWS *
**Wichtig**
Lambda verzögert gelegentlich die Einstellung einer Lambda-Laufzeit für einen begrenzten Zeitraum über das Ende der Unterstützung der Sprachversion hinaus, die von der Laufzeit unterstützt wird. Während dieses Zeitraums wendet Lambda nur Sicherheits-Patches auf das Laufzeit-Betriebssystem an. Lambda wendet keine Sicherheits-Patches auf Laufzeiten von Programmiersprachen an, nachdem diese das Ende der Unterstützung erreicht haben.
## Modell der geteilten Verantwortung
Lambda ist für das Kuratieren und Veröffentlichen von Sicherheitsupdates für alle unterstützten verwalteten Laufzeiten und Container-Basisimages verantwortlich. Standardmäßig wendet Lambda diese Aktualisierungen automatisch auf Funktionen mit verwalteten Laufzeiten an. Wenn die Standardeinstellung für automatische Laufzeit-Updates geändert wurde, finden Sie weitere Informationen im [Laufzeitmanagementkontrollen Modell der geteilten Verantwortung](runtime-management-shared.md). Bei Funktionen, die mit Container-Images bereitgestellt werden, sind Sie dafür verantwortlich, das Container-Image Ihrer Funktion aus dem neuesten Basis-Image neu zu erstellen und das Container-Image erneut bereitzustellen.
Wenn eine Laufzeit veraltet ist, erlischt die Verantwortung von Lambda für die Aktualisierung der verwalteten Laufzeit- und Container-Basis-Images. Sie sind dafür verantwortlich, Ihre Funktionen so zu aktualisieren, dass sie ein unterstütztes Laufzeit- oder Basis-Image verwenden.
In allen Fällen sind Sie dafür verantwortlich, Aktualisierungen an Ihrem Funktionscode, einschließlich seiner Abhängigkeiten, vorzunehmen. Ihre Verantwortlichkeiten im Rahmen des Modells der gemeinsamen Verantwortung sind in der folgenden Tabelle zusammengefasst.
| Laufzeit-Lebenszyklusphase | Verantwortungen von Lambda | Ihre Aufgaben |
| --- | --- | --- |
| Unterstützte verwaltete Laufzeit | Stellen Sie regelmäßige Laufzeit-Updates mit Sicherheitspatches und anderen Updates bereit. Wenden Sie Laufzeit-Updates standardmäßig automatisch an (Informationen zu nicht standardmäßigen Verhaltensweisen finden Sie unter [Modi der Laufzeitaktualisierung](runtimes-update.md#runtime-management-controls)). | Aktualisieren Sie Ihren Funktionscode, einschließlich der Abhängigkeiten, um Schwachstellen zu schließen. |
| Unterstütztes Container-Image | Regelmäßige Aktualisierung des Container-Basis-Images mit Sicherheitspatches und anderen Updates. | Aktualisieren Sie Ihren Funktionscode, einschließlich der Abhängigkeiten, um Schwachstellen zu schließen. Erstellen Sie Ihr Container-Image regelmäßig neu und stellen Sie es erneut bereit, indem Sie das neueste Basis-Image verwenden. |
| Verwaltete Laufzeit nähert sich dem Verfall | Informieren Sie Kunden per Dokumentation, E-Mail und, Health Dashboard bevor Runtime veraltet ist. Trusted Advisor Die Verantwortung für Laufzeit-Updates endet mit dem Zeitpunkt, an dem sie veraltet sind. | Überwachen Sie die Lambda-Dokumentation Health Dashboard, E-Mails oder Informationen Trusted Advisor zu veralteten Laufzeiten. Führen Sie ein Upgrade von Funktionen auf eine unterstützte Laufzeit durch, bevor die vorherige Laufzeit veraltet ist. |
| Container-Image nähert sich der Veralterung | Benachrichtigungen über veraltete Versionen sind für Funktionen, die Container-Images verwenden, nicht verfügbar. Die Verantwortung für Container-Basis-Images-Updates endet mit dem Zeitpunkt, an dem sie veraltet sind. | Beachten Sie die Zeitpläne für veraltete Versionen und aktualisieren Sie Funktionen auf ein unterstütztes Basis-Image, bevor das vorherige Image veraltet ist. |
## Unterstützung der Verwendung nach der Einstellung
Wenn eine Runtime veraltet ist, AWS dürfen keine Sicherheitspatches oder Updates mehr auf diese Runtime angewendet werden, und Funktionen, die diese Runtime verwenden, haben keinen Anspruch mehr auf technischen Support. Sie können Ihre Funktionen zwar unbegrenzt weiter aufrufen, es wird jedoch AWS dringend empfohlen, zu einer unterstützten Runtime zu migrieren. Veraltete Laufzeiten werden „wie sie sind“ ohne jegliche Garantie bereitgestellt und können Bugs, Fehler, Defekte oder andere Schwachstellen enthalten. Bei Funktionen, die eine veraltete Laufzeit verwenden, kann es zu Leistungseinbußen oder anderen Problemen kommen, wie z. B. dem Ablauf eines Zertifikats, was dazu führen kann, dass sie nicht mehr richtig funktionieren.
Sie können eine Funktion so aktualisieren, dass sie jederzeit eine neuere unterstützte Laufzeit verwendet, nachdem eine Laufzeit veraltet ist. Wir empfehlen, Ihre Funktion mit der neuen Laufzeit zu testen, bevor Sie Änderungen in Produktionsumgebungen vornehmen. Sie können nicht zur veralteten Laufzeit zurückkehren, nachdem Funktionsaktualisierungen blockiert wurden. Wir empfehlen die Verwendung von Funktions[versionen](configuration-versions.md) und [Alias](configuration-aliases.md)namen, um eine sichere Bereitstellung mit Rollback zu ermöglichen.
Die folgende Zeitleiste beschreibt, was geschieht, wenn eine Laufzeit veraltet ist:
| Laufzeit-Lebenszyklusphase | Wann | Was |
| --- | --- | --- |
| Frist für Hinweis zur Einstellung | Mindestens 180 Tage vor Ablauf der Einstellung | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html) |
| Ablehnung | Datum der Veraltung | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html) |
| Blockfunktion erstellen | Mindestens 30 Tage nach der Einstellung | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html) |
| Blockfunktion aktualisieren | Mindestens 60 Tage nach der Einstellung | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html) |
**Anmerkung**
Bei einigen Laufzeiten verschiebt AWS sich das block-function-update Datum block-function-create und die Datumsangaben über die üblichen 30 und 60 Tage nach der Deprecation hinaus. AWS hat diese Änderung als Reaktion auf Kundenfeedback vorgenommen, damit Sie mehr Zeit haben, Ihre Funktionen zu aktualisieren. In den Tabellen in [Unterstützte Laufzeiten](#runtimes-supported) und [Veraltete Laufzeitumgebungen](#runtimes-deprecated) finden Sie die Daten für Ihre Laufzeit. Lambda beginnt nicht vor den in diesen Tabellen angegebenen Terminen mit dem Blockieren von Funktionserstellungen oder -aktualisierungen.
## Empfangen von Benachrichtigungen über veraltete Laufzeitversionen
Wenn sich eine Laufzeit ihrem Verfallsdatum nähert, sendet Lambda Ihnen eine E-Mail-Benachrichtigung, falls Funktionen in Ihrer Umgebung diese Laufzeit AWS-Konto verwenden. Benachrichtigungen werden auch in und in angezeigt. Health Dashboard AWS Trusted Advisor
+ Empfangen von E-Mail-Benachrichtigungen:
Lambda sendet Ihnen mindestens **180 Tage**, bevor eine Laufzeit veraltet ist, eine E-Mail-Warnung. In dieser E-Mail sind die \$1LATEST-Versionen aller Funktionen aufgeführt, die die Laufzeit verwenden. Eine vollständige Liste der betroffenen Funktionsversionen finden Sie unter Trusted Advisor oder[Rufen Sie Daten über Lambda-Funktionen ab, die eine veraltete Laufzeit verwenden](runtimes-list-deprecated.md).
Lambda sendet eine E-Mail-Benachrichtigung an Ihren AWS-Konto primären Kontokontakt. Informationen zum Anzeigen oder Aktualisieren der E-Mail-Adressen in Ihrem Konto finden Sie in der *allgemeinen AWS -Referenz* unter [Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html).
+ Empfangen von Benachrichtigungen über: Health Dashboard
Health Dashboard Zeigt mindestens **180 Tage**, bevor eine Laufzeit veraltet ist, eine Benachrichtigung an. Benachrichtigungen werden auf der Seite **Ihr Kontostatus** unter [Andere Benachrichtigungen](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications) angezeigt. Auf der Registerkarte **Betroffene Ressourcen** in der Benachrichtigung sind die \$1LATEST-Versionen aller Funktionen aufgeführt, die die Laufzeit verwenden.
**Anmerkung**
Eine vollständige up-to-date Liste der betroffenen Funktionsversionen finden Sie unter Trusted Advisor oder. [Rufen Sie Daten über Lambda-Funktionen ab, die eine veraltete Laufzeit verwenden](runtimes-list-deprecated.md)
Health Dashboard Benachrichtigungen laufen 90 Tage ab, nachdem die betroffene Runtime veraltet ist.
+ Verwenden AWS Trusted Advisor
Trusted Advisor zeigt mindestens **180 Tage**, bevor eine Laufzeit veraltet ist, eine Benachrichtigung an. Benachrichtigungen werden auf der Seite [Sicherheit](https://console.aws.amazon.com/trustedadvisor/home#/category/security) angezeigt. Eine Liste der betroffenen Funktionen wird unter **AWS Lambda -Funktionen, die veraltete Laufzeiten verwenden** angezeigt. Diese Liste von Funktionen zeigt sowohl die \$1LATEST als auch veröffentlichte Versionen und wird automatisch aktualisiert, um den aktuellen Status Ihrer Funktionen widerzuspiegeln.
Sie können wöchentliche E-Mail-Benachrichtigungen auf der Trusted Advisor Seite [„Einstellungen“](https://console.aws.amazon.com/trustedadvisor/home?#/preferences) der Trusted Advisor Konsole aktivieren.
## Veraltete Laufzeitumgebungen
Die folgenden Laufzeiten haben das Ende der Unterstützung erreicht:
| Name | ID | Betriebssystem | Datum der Veraltung | Blockfunktion erstellen | Blockfunktion aktualisieren |
| --- | --- | --- | --- | --- | --- |
| Python 3.9 | python3.9 | Amazon Linux 2 | 15. Dezember 2025 | 31. August 2026 | 30. September 2026 |
| Node.js 18 | nodejs18.x | Amazon Linux 2 | 1. Sept. 2025 | 31. August 2026 | 30. September 2026 |
| .NET 6 | dotnet6 | Amazon Linux 2 | 20. Dezember 2024 | 31. August 2026 | 30. September 2026 |
| Python 3.8 | python3.8 | Amazon Linux 2 | 14. Oktober 2024 | 31. August 2026 | 30. September 2026 |
| Node.js 16 | nodejs16.x | Amazon Linux 2 | 12. Juni 2024 | 31. August 2026 | 30. September 2026 |
| .NET 7 (nur Container) | dotnet7 | Amazon Linux 2 | 14. Mai 2024 | – | – |
| Java 8 | java8 | Amazon Linux | 8. Januar 2024 | 8. Februar 2024 | 30. September 2026 |
| Go 1.x | go1.x | Amazon Linux | 8. Januar 2024 | 8. Februar 2024 | 30. September 2026 |
| Reine OS-Laufzeit | provided | Amazon Linux | 8. Januar 2024 | 8. Februar 2024 | 30. September 2026 |
| Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 7. Dezember 2023 | 9. Januar 2024 | 30. September 2026 |
| Node.js 14 | nodejs14.x | Amazon Linux 2 | 4. Dezember 2023 | 9. Januar 2024 | 30. September 2026 |
| Python 3.7 | python3.7 | Amazon Linux | 4. Dezember 2023 | 9. Januar 2024 | 30. September 2026 |
| .NET Core 3.1 | dotnetcore3.1 | Amazon Linux 2 | 3. Apr 2023 | 3. Apr 2023 | 3. Mai 2023 |
| Node.js 12 | nodejs12.x | Amazon Linux 2 | 31. März 2023 | 31. März 2023 | 30. Apr 2023 |
| Python 3.6 | python3.6 | Amazon Linux | 18. Juli 2022 | 18. Juli 2022 | 29. August 2022 |
| .NET 5 (nur Container) | dotnet5.0 | Amazon Linux 2 | 10. Mai 2022 | – | – |
| .NET Core 2.1 | dotnetcore2.1 | Amazon Linux | 5. Januar 2022 | 5. Januar 2022 | 13. Apr 2022 |
| Node.js 10 | nodejs10.x | Amazon Linux 2 | 30. Juli 2021 | 30. Juli 2021 | 14. Februar 2022 |
| Ruby 2.5 | ruby2.5 | Amazon Linux | 30. Juli 2021 | 30. Juli 2021 | 31. März 2022 |
| Python 2.7 | python2.7 | Amazon Linux | 15. Juli 2021 | 15. Juli 2021 | 30. Mai 2022 |
| Node.js 8.10 | nodejs8.10 | Amazon Linux | 6. März 2020 | 4. Februar 2020 | 6. März 2020 |
| Node.js 4.3 | nodejs4.3 | Amazon Linux | 5. März 2020 | 3. Februar 2020 | 5. März 2020 |
| Node.js 4.3 edge | nodejs4.3-edge | Amazon Linux | 5. März 2020 | 31. März 2019 | 30. Apr 2019 |
| Node.js 6.10 | nodejs6.10 | Amazon Linux | 12. August 2019 | 12. Juli 2019 | 12. August 2019 |
| .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 27. Juni 2019 | 30. Juni 2019 | 30. Juli 2019 |
| .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 30. Mai 2019 | 30. Apr 2019 | 30. Mai 2019 |
| Node.js 0.10 | nodejs | Amazon Linux | 30. August 2016 | 30. September 2016 | 31. Oktober 2016 |
In fast allen Fällen ist das end-of-life Datum einer Sprachversion oder eines Betriebssystems weit im Voraus bekannt. Die folgenden Links enthalten end-of-life Zeitpläne für jede Sprache, die Lambda als verwaltete Laufzeit unterstützt.
**Richtlinien für die Unterstützung von Sprache und Framework-Bedingungen**
+ **Node.js** – [github.com](https://github.com/nodejs/Release#release-schedule)
+ **Python** – [devguide.python.org](https://devguide.python.org/versions/#versions)
+ **Ruby** – [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/)
+ **Java** [— [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) und Corretto FAQs](https://aws.amazon.com/corretto/faqs/)
+ **Go** – [golang.org](https://golang.org/doc/devel/release.html)
+ **.NET** – [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core)
# Verstehen, wie Lambda Laufzeit-Versionsupdates verwaltet
Lambda hält jede verwaltete Laufzeit mit Sicherheitsupdates, Fehlerbehebungen, neuen Funktionen, Leistungsverbesserungen und Unterstützung für Nebenversionen auf dem neuesten Stand. Diese Laufzeitaktualisierungen werden als *Laufzeitversionen* veröffentlicht. Lambda wendet Laufzeitaktualisierungen auf Funktionen an, indem es die Funktion von einer früheren Laufzeitversion auf eine neue Laufzeitversion migriert.
Für Funktionen, die verwaltete Laufzeiten verwenden, wendet Lambda Laufzeitaktualisierungen standardmäßig automatisch an. Mit automatischen Laufzeitaktualisierungen übernimmt Lambda den operativen Aufwand für das Patchen der Laufzeitversionen. Für die meisten Kunden sind automatische Aktualisierungen die richtige Wahl. Sie können dieses Standardverhalten ändern, indem Sie die [Einstellungen für die Laufzeitverwaltung konfigurieren](runtime-management-configure-settings.md).
Lambda veröffentlicht auch jede neue Laufzeitversion als Container-Image. Um Laufzeitversionen für Container-basierte Funktionen zu aktualisieren, müssen Sie [ein neues Container-Image aus dem aktualisierten Basis-Image erstellen](images-create.md) und Ihre Funktion erneut bereitstellen.
Jeder Laufzeitversion ist eine Versionsnummer und ein ARN (Amazon Resource Name) zugeordnet. Laufzeitversionsnummern verwenden ein von Lambda definiertes Nummerierungsschema, unabhängig von den Versionsnummern, die die Programmiersprache verwendet. Laufzeit-Versionsnummern sind nicht immer fortlaufend. Auf Version 42 könnte beispielsweise Version 45 folgen. Der Laufzeitversions-ARN ist eine eindeutige Kennung für jede Laufzeitversion. Sie können den ARN der aktuellen Laufzeitversion Ihrer Funktion in der Lambda-Konsole oder in der [`INIT_START`-Zeile der Funktionsprotokolle](runtime-management-identify.md) anzeigen.
Laufzeitversionen sollten nicht mit Laufzeitkennungen verwechselt werden. Jede Laufzeit hat eine eindeutige **Laufzeitkennung**, z. B. `python3.14` oder `nodejs24.x`. Diese entsprechen den jeweiligen Hauptversionen der Programmiersprachen. Laufzeitversionen beschreiben die Patch-Version einer einzelnen Laufzeit.
**Anmerkung**
Der ARN für dieselbe Runtime-Versionsnummer kann je nach AWS-Regionen CPU-Architektur variieren.
**Topics**
+ [
## Abwärtskompatibilität
](#runtime-update-compatibility)
+ [
## Modi der Laufzeitaktualisierung
](#runtime-management-controls)
+ [
## Zweiphasiges Rollout der Laufzeitversion
](#runtime-management-two-phase)
+ [
# Konfigurieren der Einstellungen für die Lambda-Laufzeitverwaltung
](runtime-management-configure-settings.md)
+ [
# Rollback einer Lambda-Laufzeitversion
](runtime-management-rollback.md)
+ [
# Identifizieren von Änderungen der Lambda-Laufzeitversion
](runtime-management-identify.md)
+ [
# Verstehen des Modells der geteilten Verantwortung für die Verwaltung der Lambda-Laufzeit
](runtime-management-shared.md)
+ [
# Kontrolle der Lambda-Laufzeitaktualisierungsberechtigungen für Anwendungen mit hoher Konformität
](runtime-management-hc-applications.md)
## Abwärtskompatibilität
Lambda ist bestrebt, Laufzeitaktualisierungen bereitzustellen, die mit vorhandenen Funktionen abwärtskompatibel sind. Wie beim Software-Patching gibt es jedoch seltene Fälle, in denen sich eine Laufzeitaktualisierung negativ auf eine vorhandene Funktion auswirken kann. Beispielsweise können Sicherheits-Patches ein zugrunde liegendes Problem mit einer vorhandenen Funktion aufdecken, das vom vorherigen, unsicheren Verhalten abhängt.
Beim Erstellen und Bereitstellen Ihrer Funktion ist es wichtig zu verstehen, wie Sie Ihre Abhängigkeiten verwalten, um mögliche Inkompatibilitäten mit einem zukünftigen Laufzeit-Update zu vermeiden. Nehmen wir zum Beispiel an, dass Ihre Funktion von Paket A abhängig ist, das wiederum von Paket B abhängt. Beide Pakete sind in der Lambda-Laufzeit enthalten (sie könnten beispielsweise Teile des SDK oder seiner Abhängigkeiten oder Teile der Laufzeitsystembibliotheken sein).
Betrachten Sie folgende Szenarien:
| Bereitstellung | Patching-kompatibel | Grund |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/runtimes-update.html) | Ja | Zukünftige Laufzeit-Updates für die Pakete A und B sind abwärtskompatibel. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/runtimes-update.html) | Ja | Ihre Bereitstellung hat Vorrang, sodass zukünftige Laufzeit-Updates für die Pakete A und B keine Auswirkungen haben. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/runtimes-update.html) | Ja\$1 | Zukünftige Laufzeit-Updates für das Paket B sind abwärtskompatibel. \$1 Wenn A und B eng miteinander verbunden sind, können Kompatibilitätsprobleme auftreten. Beispielsweise sollten die `botocore` Pakete `boto3` und im AWS SDK für Python zusammen bereitgestellt werden. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/runtimes-update.html) | Nein | Zukünftige Laufzeit-Updates für Paket A erfordern möglicherweise eine aktualisierte Version von Paket B. Die bereitgestellte Version von Paket B hat jedoch Vorrang und ist möglicherweise nicht mit der aktualisierten Version von Paket A aufwärtskompatibel. |
Befolgen Sie die folgenden bewährten Methoden, um die Kompatibilität mit zukünftigen Laufzeit-Updates aufrechtzuerhalten:
+ **Wenn möglich, packen Sie alle Abhängigkeiten: Nehmen Sie** alle erforderlichen Bibliotheken, einschließlich des AWS SDK und seiner Abhängigkeiten, in Ihr Bereitstellungspaket auf. Dadurch wird ein stabiler, kompatibler Satz von Komponenten gewährleistet.
+ **Verwenden Sie runtime-provided SDKs sparsam:** Verlassen Sie sich nur dann auf das Runtime-bereitgestellte SDK, wenn Sie keine zusätzlichen Pakete hinzufügen können (z. B. wenn Sie den Lambda-Konsolen-Code-Editor oder Inline-Code in einer Vorlage verwenden). AWS CloudFormation
+ **Vermeiden Sie das Überschreiben von Systembibliotheken:** Stellen Sie keine benutzerdefinierten Betriebssystembibliotheken bereit, die mit zukünftigen Laufzeit-Updates in Konflikt geraten könnten.
## Modi der Laufzeitaktualisierung
Lambda ist bestrebt, Laufzeitaktualisierungen bereitzustellen, die mit vorhandenen Funktionen abwärtskompatibel sind. Wie beim Software-Patching gibt es jedoch seltene Fälle, in denen sich eine Laufzeitaktualisierung negativ auf eine vorhandene Funktion auswirken kann. Beispielsweise können Sicherheits-Patches ein zugrunde liegendes Problem mit einer vorhandenen Funktion aufdecken, das vom vorherigen, unsicheren Verhalten abhängt. Lambda-Laufzeitverwaltungskontrollen tragen dazu bei, das Risiko von Auswirkungen auf Ihre Workloads im seltenen Fall einer Inkompatibilität einer Laufzeitversion zu verringern. Für jede [Funktionsversion](configuration-versions.md) (`$LATEST` oder veröffentlichte Version) können Sie einen der folgenden Laufzeitaktualisierungsmodi wählen:
+ **Automatisch (Standard)** – Automatische Aktualisierung auf die neueste und sicherste Laufzeitversion mit [Zweiphasiges Rollout der Laufzeitversion](#runtime-management-two-phase). Diesen Modus empfehlen wir den meisten Kunden, damit Sie immer von Laufzeitaktualisierungen profitieren.
+ **Funktion aktualisieren** – Aktualisieren Sie die Laufzeit Ihrer Funktion auf die neueste und sicherste Laufzeitversion. Wenn Sie Ihre Funktion aktualisieren, aktualisiert Lambda die Laufzeit Ihrer Funktion auf die neueste und sicherste Laufzeitversion. Dieser Ansatz synchronisiert Laufzeitaktualisierungen mit Funktionsbereitstellungen, sodass Sie die Kontrolle darüber haben, wann Lambda Laufzeitaktualisierungen anwendet. In diesem Modus können Sie seltene Inkompatibilitäten bei Laufzeitaktualisierungen frühzeitig erkennen und beheben. Wenn Sie diesen Modus verwenden, müssen Sie Ihre Funktionen regelmäßig aktualisieren, um deren Laufzeit auf dem neuesten Stand zu halten.
+ **Manuell** – Aktualisieren Sie Ihre Laufzeitversion manuell. Sie geben in Ihrer Funktionskonfiguration eine Laufzeitversion an. Die Funktion verwendet diese Laufzeitversion unbegrenzt. In dem seltenen Fall, dass eine neue Laufzeitversion mit einer vorhandenen Funktion nicht kompatibel ist, können Sie diesen Modus verwenden, um Ihre Funktion auf eine frühere Laufzeitversion zurückzusetzen. Wir raten davon ab, den Modus **Manual** (Manuell) zu verwenden, um Laufzeitkonsistenz über Bereitstellungen hinweg zu erreichen. Weitere Informationen finden Sie unter [Rollback einer Lambda-Laufzeitversion](runtime-management-rollback.md).
Die Verantwortung für das Anwenden von Laufzeitaktualisierungen auf Ihre Funktionen hängt davon ab, welchen Laufzeitaktualisierungsmodus Sie auswählen. Weitere Informationen finden Sie unter [Verstehen des Modells der geteilten Verantwortung für die Verwaltung der Lambda-Laufzeit](runtime-management-shared.md).
## Zweiphasiges Rollout der Laufzeitversion
Lambda führt neue Laufzeitversionen in der folgenden Reihenfolge ein:
1. In der ersten Phase wendet Lambda die neue Laufzeitversion an, sobald Sie eine Funktion erstellen oder aktualisieren. Eine Funktion wird aktualisiert, wenn Sie die oder API-Operationen aufrufen. [UpdateFunctionCode[UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
1. In der zweiten Phase aktualisiert Lambda alle Funktionen, die den **Auto** (Automatischen) Laufzeitaktualisierungsmodus verwenden und die noch nicht auf die neue Laufzeitversion aktualisiert wurden.
Die Gesamtdauer des Rollout-Prozesses hängt von mehreren Faktoren ab, einschließlich des Schweregrads von Sicherheits-Patches, die in der Laufzeitaktualisierung enthalten sind.
Wenn Sie Ihre Funktionen aktiv entwickeln und bereitstellen, werden Sie höchstwahrscheinlich in der ersten Phase neue Laufzeitversionen abrufen. Dadurch werden Laufzeitaktualisierungen mit Funktionsaktualisierungen synchronisiert. In dem seltenen Fall, dass die neueste Laufzeitversion Ihre Anwendung negativ beeinflusst, können Sie mit diesem Ansatz, umgehend Korrekturmaßnahmen ergreifen. Funktionen, die sich nicht in der aktiven Entwicklung befinden, erhalten auch in der zweiten Phase den operativen Nutzen von automatischen Laufzeitaktualisierungen.
Dieser Ansatz wirkt sich nicht auf Funktionen aus, die auf **Function update** (Funktionsaktualisierung) oder **Manual** (Manuell) festgelegt sind. Funktionen, die den Modus **Function update** (Funktionsaktualisierung) verwenden, erhalten die neuesten Laufzeitaktualisierungen nur, wenn Sie sie erstellen oder aktualisieren. Funktionen, die den Modus **Manual** (Manuell) verwenden, erhalten keine Laufzeitaktualisierungen.
Lambda veröffentlicht neue Laufzeitversionen schrittweise und fortlaufend in allen AWS-Regionen. Wenn Ihre Funktionen auf die Modi **Auto** (Automatisch) oder **Function update** (Funktionsaktualisierung) festgelegt sind, ist es möglich, dass Funktionen, die zur gleichen Zeit in verschiedenen Regionen oder zu verschiedenen Zeiten in derselben Region eingesetzt werden, unterschiedliche Laufzeitversionen abrufen. Kunden, die eine garantierte Konsistenz der Laufzeitversionen in ihren Umgebungen benötigen, sollten [Container-Images verwenden, um ihre Lambda-Funktionen bereitzustellen](images-create.md). Der Modus **Manuell** ist als vorübergehende Gegenmaßnahme gedacht, um im seltenen Fall eines Laufzeitzeitproblems ein Laufzeit-Rollback zu ermöglichen, dass eine Laufzeitversion nicht mit Ihrer Funktion kompatibel ist.
# Konfigurieren der Einstellungen für die Lambda-Laufzeitverwaltung
Sie können die Laufzeitverwaltungseinstellungen mithilfe der Lambda-Konsole oder der AWS Command Line Interface (AWS CLI) konfigurieren.
**Anmerkung**
Sie können die Laufzeitverwaltungseinstellungen für jede [Funktionsversion](configuration-versions.md) separat konfigurieren.
**So konfigurieren Sie, wie Lambda Ihre Laufzeitversion aktualisiert (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie den Namen einer Funktion aus.
1. Wählen Sie auf der Registerkarte **Code** unter **Runtime settings** (Laufzeiteinstellungen) die Option **Edit runtime management configuration** (Laufzeitverwaltungskonfiguration bearbeiten) aus.
1. Wählen Sie unter **Runtime management configuration** (Laufzeitverwaltungskonfiguration) eine der folgenden Optionen aus:
+ Um Ihre Funktion automatisch auf die neueste Laufzeitversion aktualisieren zu lassen, wählen Sie **Auto** (Automatisch).
+ Um Ihre Funktion auf die neueste Laufzeitversion zu aktualisieren, wenn Sie die Funktion ändern, wählen Sie **Function update** (Funktionsaktualisierung).
+ Damit Ihre Funktion nur dann auf die neueste Laufzeitversion aktualisiert wird, wenn Sie den Laufzeitversions-ARN ändern, wählen Sie **Manual** (Manuell). Sie finden den Laufzeitversions-ARN unter **Runtime management configuration** (Laufzeitverwaltungskonfiguration). Sie finden den ARN auch in der `INIT_START`-Zeile Ihrer Funktionsprotokolle.
Weitere Informationen zu diesen Optionen finden Sie unter [Laufzeitaktualisierungsmodi](runtimes-update.md#runtime-management-controls).
1. Wählen Sie **Speichern**.
**So konfigurieren Sie, wie Lambda Ihre Laufzeitversion aktualisiert (AWS CLI)**
Um das Laufzeitmanagement für eine Funktion zu konfigurieren, führen Sie den AWS CLI-Befehl [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html) aus. Wenn Sie den `Manual`-Modus verwenden, müssen Sie auch den ARN der Laufzeitversion angeben.
```
aws lambda put-runtime-management-config \
--function-name my-function \
--update-runtime-on Manual \
--runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1
```
Die Ausgabe sollte folgendermaßen oder ähnlich aussehen:
```
{
"UpdateRuntimeOn": "Manual",
"FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
"RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1"
}
```
# Rollback einer Lambda-Laufzeitversion
In dem seltenen Ereignis, dass eine neue Laufzeitversion nicht mit Ihrer vorhandenen Funktion kompatibel ist, können Sie deren Laufzeitversion auf eine frühere Version zurücksetzen. Dadurch bleibt Ihre Anwendung funktionsfähig und die Unterbrechung wird minimiert. Gleichzeitig wird Zeit bereitgestellt, um die Inkompatibilität zu beheben, bevor Sie zur neuesten Laufzeitversion zurückkehren.
Lambda legt keine zeitliche Begrenzung fest, wie lange Sie eine bestimmte Laufzeitversion verwenden können. Wir empfehlen jedoch dringend, so schnell wie möglich auf die neueste Laufzeitversion zu aktualisieren, um von den neuesten Sicherheits-Patches, Leistungsverbesserungen und Funktionen zu profitieren. Lambda bietet die Option, auf eine frühere Laufzeitversion zurückzusetzen, nur als vorübergehende Abhilfe für den seltenen Fall eines Kompatibilitätsproblems bei Laufzeitaktualisierungen. Bei Funktionen, die über einen längeren Zeitraum eine frühere Laufzeitversion verwenden, kann es zu Leistungseinbußen oder Problemen kommen, wie z. B. dem Ablauf eines Zertifikats, was dazu führen kann, dass sie nicht mehr richtig funktionieren.
Sie können eine Laufzeitversion auf die folgenden Arten zurücksetzen:
+ [Verwenden des Manual (Manuellen) Laufzeitaktualisierungsmodus](#runtime-management-rollback-manual)
+ [Verwenden veröffentlichter Funktionsversionen](#runtime-management-rollback-published)
Weitere Informationen finden Sie unter [Einführung von AWS Lambda-Laufzeitverwaltungs-Kontrollen](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/) im AWS-Computing-Blog.
## Rollback einer Laufzeitversion mit dem Manual (Manuellen) Laufzeitaktualisierungsmodus
Wenn Sie den **Auto** (Automatischen) Aktualisierungsmodus für die Laufzeitversion oder die `$LATEST`-Laufzeitversion verwenden, können Sie Ihre Laufzeitversion im **Manual** (Manuellen) Modus zurücksetzen. Ändern Sie für die [Funktionsversion](configuration-versions.md), die Sie zurücksetzen möchten, den Aktualisierungsmodus der Laufzeitversion zu **Manual** (Manuell) und geben Sie den ARN der vorherigen Laufzeitversion an. Weitere Informationen zum Ermitteln des ARN der vorherigen Laufzeitversion finden Sie unter [Identifizieren von Änderungen der Lambda-Laufzeitversion](runtime-management-identify.md).
**Anmerkung**
Wenn die `$LATEST`-Version Ihrer Funktion für den Modus **Manual** (Manuell) konfiguriert ist, können Sie die von Ihrer Funktion verwendete CPU-Architektur oder Laufzeitversion nicht ändern. Um diese Änderungen vorzunehmen, müssen Sie in den Modus **Auto** (Automatisch) oder **Function update** (Funktionsaktualisierung) wechseln.
## Rollback einer Laufzeitversion mit veröffentlichten Funktionsversionen
Veröffentlichte [Funktionsversionen](configuration-versions.md) sind eine unveränderliche Momentaufnahme des `$LATEST`-Funktionscodes und der Konfiguration zum Zeitpunkt ihrer Erstellung. Im Modus **Auto** (Automatisch) aktualisiert Lambda während der zweiten Phase des Rollouts der Laufzeitversion automatisch die Laufzeitversion der veröffentlichten Funktionsversionen. Im Modus **Function update** (Funktionsaktualisierung) aktualisiert Lambda die Laufzeitversion veröffentlichter Funktionsversionen nicht.
Veröffentlichte Funktionsversionen, die den Modus **Function update** (Funktionsaktualisierung) verwenden, erstellen daher einen statischen Snapshot des Funktionscodes, der Konfiguration und der Laufzeitversion. Wenn Sie den Modus **Function update** (Funktionsaktualisierung) mit Funktionsversionen verwenden, können Sie Laufzeitaktualisierungen mit Ihren Bereitstellungen synchronisieren. Sie können auch das Rollback von Code-, Konfigurations- und Laufzeitversionen koordinieren, indem Sie den Datenverkehr auf eine zuvor veröffentlichte Funktionsversion umleiten. Sie können diesen Ansatz in Ihre kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) integrieren, um im seltenen Fall einer Inkompatibilität von Laufzeitaktualisierungen ein vollautomatisches Rollback durchzuführen. Wenn Sie diesen Ansatz verwenden, müssen Sie Ihre Funktion regelmäßig aktualisieren und neue Funktionsversionen veröffentlichen, um die neuesten Laufzeitaktualisierungen zu erhalten. Weitere Informationen finden Sie unter [Verstehen des Modells der geteilten Verantwortung für die Verwaltung der Lambda-Laufzeit](runtime-management-shared.md).
# Identifizieren von Änderungen der Lambda-Laufzeitversion
Die [Laufzeit-Versionsnummer](runtimes-update.md) und der ARN werden in der `INIT_START`-Protokollzeile protokolliert, die Lambda jedes Mal, wenn es eine neue [Ausführungsumgebung](concepts-basics.md#gettingstarted-concepts-runtime) erstellt, an CloudWatch Logs ausgibt. Da die Ausführungsumgebung für alle Funktionsaufrufe dieselbeLaufzeit verwendet, gibt Lambda die `INIT_START`-Protokollzeile nur aus, wenn Lambda die Init-Phase ausführt. Lambda gibt diese Protokollzeile nicht für jeden Funktionsaufruf aus. Lambda gibt die Protokollzeile an CloudWatch Logs aus, diese ist jedoch in der Konsole nicht sichtbar.
**Anmerkung**
Laufzeit-Versionsnummern sind nicht immer fortlaufend. Auf Version 42 könnte beispielsweise Version 45 folgen.
**Example Beispiel für die INIT\$1START-Protokollzeile**
```
INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I
```
Anstatt direkt mit den Protokollen zu arbeiten, können Sie [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) verwenden, um Übergänge zwischen Laufzeitversionen zu identifizieren. Die folgende Regel zählt die verschiedenen Laufzeitversionen aus jeder `INIT_START`-Protokollzeile. Um die Regel zu verwenden, ersetzen Sie den Beispiel-Protokollgruppennamen `/aws/lambda/*` durch das entsprechende Präfix für Ihre Funktion oder Funktionsgruppe.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "eventType",
"In": [
"INIT_START"
]
}
],
"Keys": [
"runtimeVersion",
"runtimeVersionArn"
]
},
"LogFormat": "CLF",
"LogGroupNames": [
"/aws/lambda/*"
],
"Fields": {
"1": "eventType",
"4": "runtimeVersion",
"8": "runtimeVersionArn"
}
}
```
Der folgende Bericht zu CloudWatch Contributor Insights zeigt ein Beispiel für einen Laufzeit-Versionswechsel, wie er in der vorherigen Regel erfasst wurde. Die orange Linie zeigt die Initialisierung der Ausführungsumgebung für die frühere Laufzeitversion (**python:3.13.v12**), während die blaue Linie die Initialisierung der Ausführungsumgebung für die neue Laufzeitversion (**python:3.13.v14**) anzeigt.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/runtime_version_graph.png)
# Verstehen des Modells der geteilten Verantwortung für die Verwaltung der Lambda-Laufzeit
Lambda ist für das Kuratieren und Veröffentlichen von Sicherheitsupdates für alle unterstützten verwalteten Laufzeiten und Container-Images verantwortlich. Die Verantwortung für die Aktualisierung vorhandener Funktionen zur Verwendung der neuesten Laufzeitversion hängt davon ab, welchen Laufzeitaktualisierungsmodus Sie verwenden.
Lambda ist dafür verantwortlich, Laufzeitaktualisierungen auf alle Funktionen anzuwenden, die für den Laufzeitaktualisierungsmodus **Auto** (Automatisch) konfiguriert sind.
Für Funktionen, die mit dem Laufzeitaktualisierungsmodus **Function update** (Funktionsaktualisierung) konfiguriert sind, sind Sie für die regelmäßige Aktualisierung Ihrer Funktion verantwortlich. Lambda ist dafür verantwortlich, Laufzeitaktualisierungen anzuwenden, wenn Sie diese Aktualisierungen vornehmen. Wenn Sie Ihre Funktion nicht aktualisieren, aktualisiert Lambda die Laufzeit nicht. Wenn Sie Ihre Funktion nicht regelmäßig aktualisieren, empfehlen wir dringend, diese für automatische Laufzeitaktualisierungen zu konfigurieren, damit sie weiterhin Sicherheitsupdates erhält.
Bei Funktionen, die für den Laufzeitaktualisierungsmodus **Manual** (Manuell) konfiguriert sind, sind Sie dafür verantwortlich, Ihre Funktion zu aktualisieren, damit sie die neueste Laufzeitversion verwendet. Wir empfehlen dringend, diesen Modus nur zu verwenden, um im seltenen Ereignis einer Inkompatibilität der Laufzeitaktualisierung die Laufzeitversion vorübergehend zurückzusetzen. Wir empfehlen Ihnen außerdem, so schnell wie möglich in den Modus **Auto** (Automatisch) zu wechseln, um die Zeit zu minimieren, in der Ihre Funktionen nicht gepatcht werden.
Wenn Sie [Container-Images zum Bereitstellen Ihrer Funktionen verwenden](images-create.md), ist Lambda für das Veröffentlichen aktualisierter Basis-Images verantwortlich. In diesem Fall sind Sie dafür verantwortlich, das Container-Image Ihrer Funktion aus dem neuesten Basis-Image neu zu erstellen und das Container-Image erneut bereitzustellen.
Dies ist in der folgenden Tabelle zusammengefasst:
****
| Bereitstellungsmodus | Verantwortung von Lambda | Verantwortung des Kunden |
| --- | --- | --- |
| Verwaltete Laufzeit, Modus Auto (Automatisch) | Veröffentlichen Sie neue Laufzeitversionen mit den neuesten Patches. Wenden Sie Laufzeit-Patches auf vorhandene Funktionen an. | Führen Sie im seltenen Fall eines Kompatibilitätsproblems bei Laufzeitaktualisierungen ein Rollback auf eine frühere Laufzeitversion durch. Folgen Sie den bewährten Methoden für [Abwärtskompatibilität](runtimes-update.md#runtime-update-compatibility). |
| Verwaltete Laufzeit, Modus Function update (Funktionsaktualisierung) | Veröffentlichen Sie neue Laufzeitversionen mit den neuesten Patches. | Aktualisieren Sie die Funktionen regelmäßig, um die neueste Laufzeitversion zu erhalten. Schalten Sie eine Funktion in den Modus **Auto** (Automatisch), wenn Sie die Funktion nicht regelmäßig aktualisieren. Führen Sie im seltenen Fall eines Kompatibilitätsproblems bei Laufzeitaktualisierungen ein Rollback auf eine frühere Laufzeitversion durch. Folgen Sie den bewährten Methoden für [Abwärtskompatibilität](runtimes-update.md#runtime-update-compatibility). |
| Verwaltete Laufzeit, Modus Manual (Manuell) | Veröffentlichen Sie neue Laufzeitversionen mit den neuesten Patches. | Verwenden Sie diesen Modus nur für ein vorübergehendes Laufzeit-Rollback im seltenen Fall eines Kompatibilitätsproblems bei der Aktualisierung. Schalten Sie die Funktionen so schnell wie möglich in den Modus **Auto** (Automatisch) oder **Function update** (Funktionsaktualisierung) und auf die neueste Laufzeitversion. |
| Container-Image | Veröffentlichen Sie neue Container-Images mit den neuesten Patches. | Stellen Sie die Funktionen regelmäßig neu bereit, indem Sie das neueste Container-Basis-Image verwenden, um die neuesten Patches abzurufen. |
Weitere Informationen zur geteilten Verantwortung mit AWS finden Sie unter [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/).
# Kontrolle der Lambda-Laufzeitaktualisierungsberechtigungen für Anwendungen mit hoher Konformität
Um Patching-Anforderungen zu erfüllen, verlassen sich Lambda-Kunden in der Regel auf automatische Laufzeitaktualisierungen. Wenn Ihre Anwendung strengen Anforderungen an die Aktualität von Patches unterliegt, sollten Sie die Verwendung früherer Laufzeitversionen einschränken. Sie können die Laufzeitverwaltungskontrollen von Lambda einschränken, indem Sie AWS Identity and Access Management (IAM) verwenden, um Benutzern in Ihrem AWS-Konto den Zugriff auf die [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html)-API-Operation zu verweigern. Dieser Vorgang wird verwendet, um den Laufzeitaktualisierungsmodus für eine Funktion auszuwählen. Wenn Sie den Zugriff auf diesen Vorgang verweigern, werden alle Funktionen standardmäßig auf den Modus **Auto** (Automatisch) umgestellt. Sie können diese Einschränkung unternehmensweit anwenden, indem Sie [Service-Kontrollrichtlinien (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) verwenden. Wenn Sie eine Funktion auf eine frühere Laufzeitversion zurücksetzen müssen, können Sie von Fall zu Fall eine Richtlinienausnahme gewähren.
# Rufen Sie Daten über Lambda-Funktionen ab, die eine veraltete Laufzeit verwenden
Wenn sich eine Lambda-Laufzeit dem Ende nähert, werden Sie von Lambda per E-Mail benachrichtigt und im Laufe der Zeit benachrichtigt. Health Dashboard Trusted Advisor In diesen E-Mails und Benachrichtigungen werden die \$1LATEST-Versionen von Funktionen aufgelistet, die die Laufzeit verwenden. Um all Ihre Funktionsversionen aufzulisten, die eine bestimmte Laufzeit verwenden, können Sie die AWS Command Line Interface (AWS CLI) oder eine der folgenden verwenden. AWS SDKs
Wenn Sie über eine große Anzahl von Funktionen verfügen, die eine Laufzeit verwenden, die bald nicht mehr unterstützt wird, können Sie das AWS CLI oder auch verwenden, AWS SDKs um Aktualisierungen Ihrer am häufigsten aufgerufenen Funktionen zu priorisieren.
In den folgenden Abschnitten erfahren Sie, wie Sie Funktionen verwenden AWS CLI und Daten über Funktionen sammeln AWS SDKs , die eine bestimmte Laufzeit verwenden.
## Auflisten von Funktionsversionen, die eine bestimmte Laufzeit verwenden
Führen Sie den folgenden Befehl aus, AWS CLI um alle Ihre Funktionsversionen aufzulisten, die eine bestimmte Laufzeit verwenden. `RUNTIME_IDENTIFIER`Ersetzen Sie ihn durch den Namen der Laufzeit, die veraltet ist, und wählen Sie Ihren eigenen aus. AWS-Region Um nur die \$1LATEST-Funktionsversionen aufzulisten, lassen Sie `--function-version ALL` im Befehl weg.
```
aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn"
```
**Tipp**
Der Beispielbefehl listet Funktionen in der `us-east-1` Region für eine bestimmte Region auf. AWS-Konto Sie müssen diesen Befehl für jede Region wiederholen, in der Ihr Konto Funktionen hat, und für jede Ihrer Regionen. AWS-Konten
Sie können auch Funktionen auflisten, die eine bestimmte Laufzeit verwenden, indem Sie eine der folgenden Optionen verwenden AWS SDKs. Der folgende Beispielcode verwendet V3 AWS SDK für JavaScript und die AWS SDK für Python (Boto3) , um eine Liste der Funktionen ARNs für Funktionen zurückzugeben, die eine bestimmte Laufzeit verwenden. Der Beispielcode gibt auch die CloudWatch Protokollgruppe für jede der aufgelisteten Funktionen zurück. Sie können diese Protokollgruppe verwenden, um das Datum des letzten Aufrufs der Funktion zu ermitteln. Weitere Informationen finden Sie im folgenden Abschnitt [Identifizieren der am häufigsten und zuletzt aufgerufenen Funktionen](#runtimes-list-deprecated-statistics).
------
#### [ Node.js ]
**Example JavaScript Code zum Auflisten von Funktionen, die eine bestimmte Laufzeit verwenden**
```
import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda";
const lambdaClient = new LambdaClient();
const command = new ListFunctionsCommand({
FunctionVersion: "ALL",
MaxItems: 50
});
const response = await lambdaClient.send(command);
for (const f of response.Functions){
if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14'
console.log(f.FunctionArn);
// get the CloudWatch log group of the function to
// use later for finding the last invocation date
console.log(f.LoggingConfig.LogGroup);
}
}
// If your account has more functions than the specified
// MaxItems, use the returned pagination token in the
// next request with the 'Marker' parameter
if ('NextMarker' in response){
let paginationToken = response.NextMarker;
}
```
------
#### [ Python ]
**Example Python-Code zur Auflistung von Funktionen mit einer bestimmten Laufzeit**
```
import boto3
from botocore.exceptions import ClientError
def list_lambda_functions(target_runtime):
lambda_client = boto3.client('lambda')
response = lambda_client.list_functions(
FunctionVersion='ALL',
MaxItems=50
)
if not response['Functions']:
print("No Lambda functions found")
else:
for function in response['Functions']:
if function['PackageType']=='Zip' and function['Runtime'] == target_runtime:
print(function['FunctionArn'])
# Print the CloudWatch log group of the function
# to use later for finding last invocation date
print(function['LoggingConfig']['LogGroup'])
if 'NextMarker' in response:
pagination_token = response['NextMarker']
if __name__ == "__main__":
# Replace python3.12 with the appropriate runtime ID for your Lambda functions
list_lambda_functions('python3.12')
```
------
Weitere Informationen zur Verwendung eines AWS SDK zum Auflisten Ihrer Funktionen mithilfe der [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)Aktion finden Sie in der [SDK-Dokumentation](https://aws.amazon.com/developer/tools/) für Ihre bevorzugte Programmiersprache.
Sie können auch die Funktion AWS Config Erweiterte Abfragen verwenden, um all Ihre Funktionen aufzulisten, die eine betroffene Laufzeit verwenden. Diese Abfrage gibt nur die Versionen der Funktion \$1LATEST zurück, aber Sie können Abfragen aggregieren, um Funktionen für alle Regionen und mehrere Regionen AWS-Konten mit einem einzigen Befehl aufzulisten. Weitere Informationen finden Sie unter [Abfragen des aktuellen Konfigurationsstatus von AWS Auto Scaling Ressourcen](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html) im *AWS Config Entwicklerhandbuch*.
## Identifizieren der am häufigsten und zuletzt aufgerufenen Funktionen
Wenn Ihre Version Funktionen AWS-Konto enthält, die eine Laufzeit verwenden, die bald veraltet sein wird, sollten Sie der Aktualisierung von Funktionen, die häufig aufgerufen werden, oder Funktionen, die kürzlich aufgerufen wurden, Priorität einräumen.
Wenn Sie nur über wenige Funktionen verfügen, können Sie die CloudWatch Logs-Konsole verwenden, um diese Informationen zu sammeln, indem Sie sich die Log-Streams Ihrer Funktionen ansehen. [Weitere Informationen finden Sie unter An Logs gesendete CloudWatch Protokolldaten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) anzeigen.
Um die Anzahl der letzten Funktionsaufrufen zu sehen, können Sie auch die in der Lambda-Konsole angezeigten CloudWatch Metrikinformationen verwenden. Gehen Sie wie folgt vor, um diese Informationen anzuzeigen:
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion aus, für die Sie eine Aufrufstatistik anzeigen möchten.
1. Wählen Sie den Tab **Überwachung**.
1. Legen Sie den Zeitraum fest, für den Sie die Statistiken anzeigen möchten, indem Sie den Datumsbereich auswählen. Die letzten Aufrufe werden im Bereich **Aufrufe** angezeigt.
Bei Konten mit einer größeren Anzahl von Funktionen kann es effizienter sein, diese Daten programmgesteuert mithilfe der AWS CLI oder einer der API-Aktionen „ AWS SDKs using the“ und zu sammeln. [DescribeLogStreams[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html)
Die folgenden Beispiele enthalten Codefragmente, die V3 AWS SDK für JavaScript und die verwenden, AWS SDK für Python (Boto3) um das Datum des letzten Aufrufs für eine bestimmte Funktion zu identifizieren und die Anzahl der Aufrufe für eine bestimmte Funktion in den letzten 14 Tagen zu bestimmen.
------
#### [ Node.js ]
**Example JavaScript Code, um die Uhrzeit des letzten Aufrufs für eine Funktion zu ermitteln**
```
import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs";
const cloudWatchLogsClient = new CloudWatchLogsClient();
const command = new DescribeLogStreamsCommand({
logGroupName: '',
orderBy: 'LastEventTime',
descending: true,
limit: 1
});
try {
const response = await cloudWatchLogsClient.send(command);
const lastEventTimestamp = response.logStreams.length > 0 ?
response.logStreams[0].lastEventTimestamp : null;
// Convert the UNIX timestamp to a human-readable format for display
const date = new Date(lastEventTimestamp).toLocaleDateString();
const time = new Date(lastEventTimestamp).toLocaleTimeString();
console.log(`${date} ${time}`);
} catch (e){
console.error('Log group not found.')
}
```
------
#### [ Python ]
**Example Python-Code, um den Zeitpunkt des letzten Aufrufs für eine Funktion zu ermitteln**
```
import boto3
from datetime import datetime
cloudwatch_logs_client = boto3.client('logs')
response = cloudwatch_logs_client.describe_log_streams(
logGroupName='',
orderBy='LastEventTime',
descending=True,
limit=1
)
try:
if len(response['logStreams']) > 0:
last_event_timestamp = response['logStreams'][0]['lastEventTimestamp']
print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds
else:
last_event_timestamp = None
except:
print('Log group not found')
```
------
**Tipp**
Sie können den Namen der Protokollgruppe Ihrer Funktion mithilfe der [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)API-Operation ermitteln. Der Code in [Auflisten von Funktionsversionen, die eine bestimmte Laufzeit verwenden](#runtimes-list-deprecated-versions) enthält ein Beispiel für diese Vorgehensweise.
------
#### [ Node.js ]
**Example JavaScript Code, um die Anzahl der Aufrufe in den letzten 14 Tagen zu ermitteln**
```
import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch";
const cloudWatchClient = new CloudWatchClient();
const command = new GetMetricStatisticsCommand({
Namespace: 'AWS/Lambda',
MetricName: 'Invocations',
StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago
EndTime: new Date(Date.now()),
Period: 86400 * 14, // 14 days.
Statistics: ['Sum'],
Dimensions: [{
Name: 'FunctionName',
Value: ''
}]
});
const response = await cloudWatchClient.send(command);
const invokesInLast14Days = response.Datapoints.length > 0 ?
response.Datapoints[0].Sum : 0;
console.log('Number of invocations: ' + invokesInLast14Days);
```
------
#### [ Python ]
**Example Python-Code, um die Anzahl der Aufrufe in den letzten 14 Tagen zu ermitteln**
```
import boto3
from datetime import datetime, timedelta
cloudwatch_client = boto3.client('cloudwatch')
response = cloudwatch_client.get_metric_statistics(
Namespace='AWS/Lambda',
MetricName='Invocations',
Dimensions=[
{
'Name': 'FunctionName',
'Value': ''
},
],
StartTime=datetime.now() - timedelta(days=14),
EndTime=datetime.now(),
Period=86400 * 14, # 14 days
Statistics=[
'Sum'
]
)
if len(response['Datapoints']) > 0:
invokes_in_last_14_days = int(response['Datapoints'][0]['Sum'])
else:
invokes_in_last_14_days = 0
print(f'Number of invocations: {invokes_in_last_14_days}')
```
------
# Ändern der Laufzeitumgebung
Sie können [interne Erweiterungen](lambda-extensions.md) verwenden, um den Laufzeitprozess zu ändern. Interne Erweiterungen sind keine separaten Prozesse – sie werden als Teil des Laufzeitprozesses ausgeführt.
Lambda bietet sprachspezifische [Umgebungsvariablen](configuration-envvars.md), die Sie festlegen können, um Optionen und Werkzeuge zur Laufzeit hinzuzufügen. Lambda bietet auch [Wrapper-Skripts](#runtime-wrapper), die Lambda erlauben, den Laufzeit-Startup an Ihr Skript zu delegieren. Sie können ein Wrapper-Skript erstellen, um das Laufzeit-Startup-Verhalten anzupassen.
## Sprachspezifische Umgebungsvariablen
Lambda unterstützt Konfigurationsmöglichkeiten, mit denen Code während der Funktionsinitialisierung über die folgenden sprachspezifischen Umgebungsvariablen vorgeladen werden kann:
+ `JAVA_TOOL_OPTIONS` – Unter Java unterstützt Lambda diese Umgebungsvariable, um zusätzliche Befehlszeilenvariablen in Lambda zu setzen. Mit dieser Umgebungsvariablen können Sie die Initialisierung von Werkzeugen angeben, insbesondere das Starten von nativen oder Java-Agenten mit den Optionen `agentlib` oder `javaagent`. Weitere Informationen finden Sie unter [`JAVA_TOOL_OPTIONS`-Umgebungsvariablen](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options).
+ `NODE_OPTIONS` – Verfügbar in [Node.js-Laufzeiten](lambda-nodejs.md).
+ `DOTNET_STARTUP_HOOKS` – Auf .NET Core 3.1 und höher gibt diese Umgebungsvariable einen Pfad zu einer Assembly (DLL) an, die Lambda verwenden kann.
Die Verwendung sprachspezifischer Umgebungsvariablen ist die bevorzugte Methode zum Festlegen von Startup-Eigenschaften.
## Wrapper-Skripte
Sie können ein *Wrapper-Skript* erstellen, um das Laufzeit-Startup-Verhalten Ihrer Lambda-Funktion anzupassen. Mit einem Wrapper-Skript können Sie Konfigurationsparameter festlegen, die nicht über sprachspezifische Umgebungsvariablen festgelegt werden können.
**Anmerkung**
Aufrufe können fehlschlagen, wenn das Wrapper-Skript den Laufzeitprozess nicht erfolgreich startet.
Wrapper-Skripts werden auf allen nativen [Lambda-Laufzeiten](lambda-runtimes.md) unterstützt. Wrapper-Skripts werden auf [Reine OS-Laufzeiten](runtimes-provided.md) (der `provided`-Laufzeitfamilie) nicht unterstützt.
Wenn Sie ein Wrapper-Skript für Ihre Funktion verwenden, startet Lambda die Laufzeit mit Ihrem Skript. Lambda sendet den Pfad an Ihr Skript zum Interpreter und alle ursprünglichen Argumente für den Startup der Standardlaufzeit. Ihr Skript kann das Startup-Verhalten des Programms erweitern oder transformieren. Beispielsweise kann das Skript Argumente injizieren und ändern, Umgebungsvariablen festlegen oder Metriken, Fehler und andere Diagnoseinformationen erfassen.
Sie geben das Skript an, indem Sie den Wert der `AWS_LAMBDA_EXEC_WRAPPER`-Umgebungsvariablen als Dateisystempfad einer ausführbaren Binärdatei oder eines Skripts festlegen.
### Beispiel: Erstellen und Verwenden eines Wrapper-Skripts als Lambda-Ebene
Im folgenden Beispiel erstellen Sie ein Wrapper-Skript, um den Python-Interpreter mit der `-X importtime`-Option zu starten. Wenn Sie die Funktion ausführen, generiert Lambda einen Protokolleintrag, der die Dauer der Importzeit für jeden Import anzeigt.
**So erstellen und verwenden Sie ein Wrapper-Skript als Ebene**
1. Erstellen Sie ein Verzeichnis für die Ebene:
```
mkdir -p python-wrapper-layer/bin
cd python-wrapper-layer/bin
```
1. Fügen Sie im Verzeichnis `bin` den folgenden Code in eine neue Datei namens `importtime_wrapper` ein. Dies ist das Wrapper-Skript.
```
#!/bin/bash
# the path to the interpreter and all of the originally intended arguments
args=("$@")
# the extra options to pass to the interpreter
extra_args=("-X" "importtime")
# insert the extra options
args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}")
# start the runtime with the extra options
exec "${args[@]}"
```
1. Geben Sie dem Skript die Berechtigung zur Ausführung:
```
chmod +x importtime_wrapper
```
1. Erstellen Sie eine ZIP-Datei für die Ebene:
```
cd ..
zip -r ../python-wrapper-layer.zip .
```
1. Vergewissern Sie sich, dass Ihre .zip-Datei die folgende Verzeichnisstruktur aufweist:
```
python-wrapper-layer.zip
└ bin
└ importtime_wrapper
```
1. [Erstellen Sie eine Ebene](creating-deleting-layers.md#layers-create) mit dem .zip-Paket.
1. Erstellen Sie eine Funktion mit der Lambda-Konsole.
1. Öffnen Sie die [Lambda-Konsole](https://console.aws.amazon.com/lambda).
1. Wählen Sie **Create function (Funktion erstellen)**.
1. Geben Sie einen **Function name** (Funktionsnamen) ein.
1. Wählen Sie für **Laufzeit** die **neueste unterstützte** Python-Laufzeit aus.
1. Wählen Sie **Create function (Funktion erstellen)**.
1. Fügen Sie die Ebene zu Ihrer Funktion hinzu.
1. Wählen Sie Ihre Funktion aus, und wählen Sie dann die Registerkarte **Code**, falls sie nicht bereits ausgewählt ist.
1. Blättern Sie nach unten bis zum Abschnitt **Ebenen** und wählen Sie dann **Eine Ebene hinzufügen**.
1. Wählen Sie unter **Ebenenquelle** die Option **Benutzerdefinierte Ebenen** und wählen Sie dann Ihre Ebene aus der Dropdown-Liste **Benutzerdefinierte Ebenen** aus.
1. Wählen Sie für **Version** die Option **1**.
1. Wählen Sie **Hinzufügen** aus.
1. Fügen Sie die Wrapper-Umgebungsvariable hinzu.
1. Wählen Sie den Tab **Configuration (Konfiguration)** und dann **Environment variables (Umgebungsvariablen)** aus.
1. Wählen Sie unter **Environment variables (Umgebungsvariablen)** die Option **Edit (Bearbeiten)**.
1. Wählen Sie **Umgebungsvariablen hinzufügen** aus.
1. Geben Sie für **Key (Schlüssel)** `AWS_LAMBDA_EXEC_WRAPPER` ein.
1. Geben Sie als **Wert** `/opt/bin/importtime_wrapper` (`/opt/`\$1 die Ordnerstruktur Ihrer ZIP-Ebene) ein.
1. Wählen Sie **Speichern**.
1. Testen Sie das Wrapper-Skript.
1. Wählen Sie die Registerkarte **Test**.
1. Wählen Sie unter **Testereignis** die Option **Test** aus. Sie brauchen kein Test-Ereignis zu erstellen – das Standard-Ereignis ist ausreichend.
1. Scrollen Sie nach unten zu **Protokollausgabe**. Da Ihr Wrapper-Skript den Python-Interpreter mit der `-X importtime`-Option gestartet hat, zeigen die Protokolle die für jeden Import erforderliche Zeit an. Zum Beispiel:
```
532 | collections
import time: 63 | 63 | _functools
import time: 1053 | 3646 | functools
import time: 2163 | 7499 | enum
import time: 100 | 100 | _sre
import time: 446 | 446 | re._constants
import time: 691 | 1136 | re._parser
import time: 378 | 378 | re._casefix
import time: 670 | 2283 | re._compiler
import time: 416 | 416 | copyreg
```
# Verwenden der Lambda-Laufzeit-API für benutzerdefinierte Laufzeiten
AWS Lambda [bietet eine HTTP-API für [benutzerdefinierte Laufzeiten](runtimes-custom.md), um Aufrufereignisse von Lambda zu empfangen und Antwortdaten innerhalb der Lambda-Ausführungsumgebung zurückzusenden.](lambda-runtimes.md) Dieser Abschnitt enthält die API-Referenz für die Lambda-Laufzeiten-API.
**Lambda Managed Instances unterstützen gleichzeitige Anfragen**
Lambda Managed Instances verwenden dieselbe Runtime-API wie Lambda-Funktionen (Standard). Der Hauptunterschied besteht darin, dass verwaltete Instances gleichzeitige `/response` Anfragen `/next` und Anfragen bis zum konfigurierten Limit akzeptieren können. `AWS_LAMBDA_MAX_CONCURRENCY` Dadurch können mehrere Aufrufe gleichzeitig in einer einzigen Ausführungsumgebung verarbeitet werden. Weitere Informationen zu verwalteten Instanzen finden Sie unter. [Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances](lambda-managed-instances-execution-environment.md)
![\[Architekturdiagramm der Ausführungsumgebung.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
Die OpenAPI-Spezifikation für die Laufzeit-API-Version **2018-06-01** ist unter [runtime-api.zip](samples/runtime-api.zip) verfügbar.
Um eine API-Anforderungs-URL zu erstellen, rufen Laufzeitumgebungen den API-Endpunkt aus der `AWS_LAMBDA_RUNTIME_API`-Umgebungsvariablen ab, fügen die API-Version und dann den gewünschten Ressourcenpfad hinzu.
**Example Anforderung**
```
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"
```
**Topics**
+ [
## Nächster Aufruf
](#runtimes-api-next)
+ [
## Aufrufantwort
](#runtimes-api-response)
+ [
## Initialisierungsfehler
](#runtimes-api-initerror)
+ [
## Aufruffehler
](#runtimes-api-invokeerror)
## Nächster Aufruf
**Pfad** – `/runtime/invocation/next`
**Methode** – **GET**
Die Laufzeit sendet diese Meldung an Lambda, um ein Aufrufereignis anzufordern. Der Antworttext enthält die Nutzlast aus dem Aufruf. Dabei handelt es sich um ein JSON-Dokument, das Ereignisdaten aus dem Funktionsauslöser enthält. Die Antwort-Header enthalten zusätzliche Daten zum Aufruf.
**Antwort-Header**
+ `Lambda-Runtime-Aws-Request-Id` – Die Anforderungs-ID, mit der die Anforderung identifiziert wird, die den Aufruf der Funktion ausgelöst hat.
Beispiel, `8476a536-e9f4-11e8-9739-2dfe598c3fcd`.
+ `Lambda-Runtime-Deadline-Ms` – Das Datum, an dem eine Zeitüberschreitung für die Funktion eintritt (in Unix-Millisekunden).
Beispiel, `1542409706888`.
+ `Lambda-Runtime-Invoked-Function-Arn` – Der ARN der/des Lambda-Funktion, -Version oder -Alias, die/der im Aufruf angegeben ist.
Beispiel, `arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`.
+ `Lambda-Runtime-Trace-Id` – Der [AWS X-Ray -Nachverfolgungs-Header](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader).
Beispiel, `Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`.
+ `Lambda-Runtime-Client-Context`— Für Aufrufe aus dem AWS Mobile SDK: Daten über die Client-Anwendung und das Gerät.
+ `Lambda-Runtime-Cognito-Identity`— Für Aufrufe aus dem AWS Mobile SDK Daten über den Amazon Cognito Cognito-Identitätsanbieter.
Legen Sie kein Timeout für die `GET`-Anfrage fest, da sich die Antwort verzögern könnte. Zwischen dem Bootstrap der Laufzeit durch Lambda und der Rückgabe eines Ereignisses durch die Laufzeit ist der Laufzeitprozess möglicherweise für mehrere Sekunden eingefroren.
Die Anforderungs-ID verfolgt den Aufruf innerhalb von Lambda nach. Sie verwenden sie, um den Aufruf anzugeben, wenn Sie die Antwort senden.
Der Nachverfolgungs-Header enthält die Nachverfolgungs-ID, die ID des übergeordneten Segments und die Erfassungsentscheidung Wenn die Anforderung erfasst wurde, wurde die Anforderung von Lambda oder einem Upstream-Service erfasst. Die Laufzeit sollte die `_X_AMZN_TRACE_ID` auf den Wert des Headers festlegen. Das X-Ray-SDK liest dies, um die Anfrage abzurufen IDs und festzustellen, ob sie verfolgt werden soll.
## Aufrufantwort
**Pfad** – `/runtime/invocation/AwsRequestId/response`
**Methode** – **POST**
Nachdem die Funktion bis zum Abschluss ausgeführt wurde, schickt die Laufzeitumgebung eine Aufrufantwort an Lambda. Im Fall synchroner Aufrufe schickt Lambda die Antwort anschließend an den Client zurück.
**Example Erfolg für Anforderung**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS"
```
## Initialisierungsfehler
Wenn die Funktion einen Fehler zurückgibt oder die Laufzeit während der Initialisierung auf einen Fehler stößt, verwendet die Laufzeit diese Methode, um den Fehler an Lambda zu melden.
**Pfad** – `/runtime/init/error`
**Methode** – **POST**
**Header**
`Lambda-Runtime-Function-Error-Type` – Der Fehlertyp, auf den die Laufzeit gestoßen ist. Erforderlich: Nein.
Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von . Beispiel:
+ Laufzeit. NoSuchHandler
+ Laufzeit. APIKeyNotFound
+ Laufzeit. ConfigInvalid
+ Laufzeit. UnknownReason
**Body-Parameter**
`ErrorRequest` – Informationen über den Fehler. Erforderlich: Nein
Dieses Feld ist ein JSON-Objekt mit der folgenden Struktur:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Beachten Sie, dass Lambda jeden Wert für `errorType` akzeptiert.
Das folgende Beispiel zeigt eine Lambda-Funktionsfehlermeldung, in der die Funktion die im Aufruf bereitgestellten Ereignisdaten nicht analysieren konnte.
**Example Funktionsfehler**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Antworttextparameter:**
+ `StatusResponse` – Zeichenfolge. Statusinformationen, gesendet mit 202 Antwortcodes.
+ `ErrorResponse`— Zusätzliche Fehlerinformationen, die zusammen mit den Fehlerantwortcodes gesendet werden. ErrorResponse enthält einen Fehlertyp und eine Fehlermeldung.
**Antwortcodes**
+ 202 – Akzeptiert
+ 403 – Verboten
+ 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Laufzeit sollte umgehend beendet werden.
**Example Initialisierungsfehleranforderung**
```
ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
## Aufruffehler
Wenn die Funktion einen Fehler zurückgibt oder die Laufzeit auf einen Fehler stößt, verwendet die Laufzeitumgebung diese Methode, um den Fehler an Lambda zu melden.
**Pfad** – `/runtime/invocation/AwsRequestId/error`
**Methode** – **POST**
**Header**
`Lambda-Runtime-Function-Error-Type` – Der Fehlertyp, auf den die Laufzeit gestoßen ist. Erforderlich: Nein.
Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von . Beispiel:
+ Laufzeit. NoSuchHandler
+ Laufzeit. APIKeyNotFound
+ Laufzeit. ConfigInvalid
+ Laufzeit. UnknownReason
**Body-Parameter**
`ErrorRequest` – Informationen über den Fehler. Erforderlich: Nein
Dieses Feld ist ein JSON-Objekt mit der folgenden Struktur:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Beachten Sie, dass Lambda jeden Wert für `errorType` akzeptiert.
Das folgende Beispiel zeigt eine Lambda-Funktionsfehlermeldung, in der die Funktion die im Aufruf bereitgestellten Ereignisdaten nicht analysieren konnte.
**Example Funktionsfehler**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Antworttextparameter:**
+ `StatusResponse` – Zeichenfolge. Statusinformationen, gesendet mit 202 Antwortcodes.
+ `ErrorResponse`— Zusätzliche Fehlerinformationen, die zusammen mit den Fehlerantwortcodes gesendet werden. ErrorResponse enthält einen Fehlertyp und eine Fehlermeldung.
**Antwortcodes**
+ 202 – Akzeptiert
+ 400 – Ungültige Anfrage
+ 403 – Verboten
+ 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Laufzeit sollte umgehend beendet werden.
**Example Fehler für Anforderung**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
# Wann sollten die reinen OS-Laufzeiten verwendet werden
Lambda bietet [verwaltete Laufzeiten](lambda-runtimes.md) für Java, Python, Node.js, .NET und Ruby. Um Lambda-Funktionen in einer Programmiersprache zu erstellen, die nicht als verwaltete Laufzeit verfügbar ist, verwenden Sie eine reine OS-Laufzeit (die `provided`-Laufzeitfamilie). Es gibt drei Hauptanwendungsfälle für reine OS-Laufzeiten:
+ **Native Kompilierung ahead-of-time (AOT)**: Sprachen wie Go, Rust, Swift und C\$1\$1 werden nativ zu einer ausführbaren Binärdatei kompiliert, für die keine spezielle Sprachlaufzeit erforderlich ist. Diese Sprachen benötigen nur eine Betriebssystemumgebung, in der die kompilierte Binärdatei ausgeführt werden kann. Sie können auch Laufzeiten verwenden, die nur auf Lambda OS basieren, um Binärdateien bereitzustellen, die mit.NET Native AOT und Java GraalVM Native Image kompiliert wurden.
Sie müssen einen Laufzeitschnitten-Client in Ihre Binärdatei aufnehmen. Der Laufzeitenschnittstellen-Client ruft die [Verwenden der Lambda-Laufzeit-API für benutzerdefinierte Laufzeiten](runtimes-api.md) auf, um Funktionsaufrufe abzurufen, und ruft dann den Funktionshandler auf. Lambda bietet Runtime-Schnittstellenclients für [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (experimentell) und [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (experimentell).
Sie müssen Ihre Binärdatei für eine Linux-Umgebung und für dieselbe Befehlssatzarchitektur kompilieren, die Sie für die Funktion verwenden möchten (x86\$164 oder arm64).
+ **Laufzeiten von Drittanbietern**: Sie können Lambda-Funktionen mit off-the-shelf Laufzeiten wie [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) für PHP ausführen.
+ **Benutzerdefinierte Laufzeiten**: Sie können Ihre eigene Laufzeit für eine Sprache oder Sprachversion erstellen, für die Lambda keine verwaltete Laufzeit bereitstellt, z. B. Node.js 19. Weitere Informationen finden Sie unter [Erstellen einer benutzerdefinierten Laufzeit für AWS Lambda](runtimes-custom.md). Dies ist der am wenigsten verbreitete Anwendungsfall für reine OS-Laufzeiten.
Lambda unterstützt die folgenden reinen OS-Laufzeiten.
| Name | ID | Betriebssystem | Datum der Veraltung | Blockfunktion erstellen | Blockfunktion aktualisieren |
| --- | --- | --- | --- | --- | --- |
| Reine OS-Laufzeit | `provided.al2023` | Amazon Linux 2023 | 30. Juni 2029 | 31. Juli 2029 | 31. August 2029 |
| Reine OS-Laufzeit | `provided.al2` | Amazon Linux 2 | 31. Juli 2026 | 31. August 2026 | 30. September 2026 |
Die Laufzeit von Amazon Linux 2023 (`provided.al2023`) bietet mehrere Vorteile gegenüber Amazon Linux 2, darunter einen geringeren Bereitstellungsaufwand und aktualisierte Versionen von Bibliotheken wie `glibc`.
Die `provided.al2023`-Laufzeit verwendet `dnf` als Paketmanager anstelle von `yum`, was der Standard-Paketmanager in Amazon Linux 2 ist. Weitere Informationen zu den Unterschieden zwischen `provided.al2023` und `provided.al2` finden Sie unter [Einführung in die Amazon Linux 2023 Runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) im AWS Compute-Blog.
# Erstellen einer benutzerdefinierten Laufzeit für AWS Lambda
Sie können eine AWS Lambda Laufzeit in jeder Programmiersprache implementieren. Eine Laufzeit ist ein Programm, das die Handler-Methode einer Lambda-Funktion ausführt, wenn die Funktion aufgerufen wird. Die Laufzeit kann im Bereitstellungspaket Ihrer Funktion enthalten sein oder in einem [Layer](chapter-layers.md) verteilt werden. Wenn Sie die Lambda-Funktion erstellen, wählen Sie eine [reine OS-Laufzeit](runtimes-provided.md) (die `provided`-Laufzeitfamilie) aus.
**Anmerkung**
Das Erstellen einer benutzerdefinierten Laufzeit ist ein Anwendungsfall für Fortgeschrittene. Informationen zur Kompilierung in eine native Binärdatei oder zur Verwendung einer off-the-shelf Runtime eines Drittanbieters finden Sie unter[Wann sollten die reinen OS-Laufzeiten verwendet werden](runtimes-provided.md).
Eine exemplarische Vorgehensweise für die Bereitstellung einer benutzerdefinierten Laufzeit finden Sie unter [Tutorial: Erstellen einer benutzerdefinierten Laufzeit](runtimes-walkthrough.md).
**Topics**
+ [
## Voraussetzungen
](#runtimes-custom-build)
+ [
## Implementieren von Antwort-Streaming in einer benutzerdefinierten Laufzeitumgebung
](#runtimes-custom-response-streaming)
+ [
## Erstellung benutzerdefinierter Laufzeiten für Lambda Managed Instances
](#runtimes-custom-managed-instances)
## Voraussetzungen
Benutzerdefinierte Laufzeiten müssen bestimmte Initialisierungs- und Verarbeitungsaufgaben abschließen. Eine Laufzeit führt den Setup-Code der Funktion aus, liest den Namen des Handlers aus einer Umgebungsvariablen und liest Aufrufereignisse von der Lambda-Laufzeit-API. Die Laufzeit übergibt die Ereignisdaten an den Funktions-Handler und sendet die Antwort aus dem Handler zurück an Lambda.
### Initialisierungsaufgaben
Die Initialisierungsaufgaben werden einmal [pro Instance der Funktion](lambda-runtime-environment.md) ausgeführt, um die Umgebung auf die Verarbeitung von Aufrufen vorzubereiten.
+ **Einstellungen abrufen** – Liest Umgebungsvariablen, um Details zu Funktion und Umgebung abzurufen.
+ `_HANDLER` – Der Speicherort für den Handler aus der Konfiguration der Funktion. Das Standardformat ist `file.method`, wobei `file` der Name der Datei ohne Erweiterung und `method` der Name einer Methode oder Funktion ist, die in der Datei definiert ist.
+ `LAMBDA_TASK_ROOT` – Das Verzeichnis, das den Funktionscode enthält.
+ `AWS_LAMBDA_RUNTIME_API` – Host und Port der Laufzeit-API.
Unter [Definierte Laufzeitumgebungsvariablen](configuration-envvars.md#configuration-envvars-runtime) finden Sie eine vollständige Liste der verfügbaren Variablen.
+ **Funktion initialisieren** – Lädt die Handler-Datei und führt den globalen oder statischen Code aus, den sie enthält. Funktionen sollten statische Ressourcen wie SDK-Clients und Datenbankverbindungen einmal erstellen und für mehrere Aufrufe wiederverwenden.
+ **Fehler verarbeiten** – Wenn ein Fehler auftritt, werden die [Initialisierungsfehler](runtimes-api.md#runtimes-api-initerror)-API aufgerufen die Ausführung sofort beendet.
Die Initialisierung zählt zur fakturierten Ausführungszeit und zum Timeout. Wenn eine Ausführung die Initialisierung einer neuen Instance Ihrer Funktion auslöst, sehen Sie die Initialisierungszeit in den Protokollen und in der [AWS X-Ray -Nachverfolgung](services-xray.md).
**Example log**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### Verarbeitungsaufgaben
Während der Ausführung verwendet eine Laufzeit die [Lambda-Laufzeitschnittstelle](runtimes-api.md), um eingehende Ereignisse zu verwalten und Fehler zu melden. Nach Abschluss der Initialisierungsaufgaben verarbeitet die Laufzeit eingehende Ereignisse in einer Schleife. Führen Sie in Ihrem Laufzeitcode die folgenden Schritte in der angegebenen Reihenfolge aus.
+ **Ereignis abrufen** – Ruft die API für den [nächsten Aufruf](runtimes-api.md#runtimes-api-next) auf, um das nächste Ereignis abzurufen. Der Antworttext enthält die Ereignisdaten. De Antwort-Header enthalten die Anforderungs-ID und andere Informationen.
+ **Nachverfolgungs-Header propagieren** – Ruft den X-Ray-Nachverfolgungs-Header aus dem `Lambda-Runtime-Trace-Id`-Header in der API-Antwort ab. Legen Sie die `_X_AMZN_TRACE_ID`-Umgebungsvariable lokal mit demselben Wert fest. Das X-Ray-SDK verwendet diesen Wert, um Ablaufverfolgungsdaten zwischen Services miteinander zu verbinden.
+ **Context-Objekt erstellen** – Erstellt ein Objekt mit Kontextinformationen aus Umgebungsvariablen und Headern in den API-Antworten.
+ **Funktions-Handler aufrufen** – Übergibt Ereignis und Context-Objekt an den Handler.
+ **Antwort verarbeiten** – Ruft die API für die [Aufrufantwort](runtimes-api.md#runtimes-api-response) ab, um die Antwort aus dem Handler zu veröffentlichen.
+ **Fehler verarbeiten** – Ruft die API für [Aufruffehler](runtimes-api.md#runtimes-api-invokeerror) auf, wenn ein Fehler auftritt.
+ **Bereinigen** Gibt nicht verwendete Ressourcen frei, sendet Daten an andere Services oder führt zusätzliche Aufgaben aus, bevor das nächste Ereignis abgerufen wird.
### Eintrittspunkt
Der Eintrittspunkt einer benutzerdefinierten Laufzeit ist eine ausführbare Datei mit dem Namen `bootstrap`. Bei der Bootstrap-Datei kann es sich um die Laufzeit handeln oder es wird eine andere Datei aufgerufen, die die Laufzeit erstellt. Wenn das Stammverzeichnis Ihres Bereitstellungspakets keine Datei mit dem Namen `bootstrap` enthält, sucht Lambda in den Funktionsschichten nach der Datei. Wenn die `bootstrap`-Datei nicht existiert oder nicht ausgeführt werden kann, gibt die Funktion beim Aufruf einen `Runtime.InvalidEntrypoint`-Fehler zurück.
Hier ist eine `bootstrap` Beispieldatei, die eine gebündelte Version von Node.js verwendet, um eine JavaScript Runtime in einer separaten Datei mit dem Namen auszuführen. `runtime.js`
**Example bootstrap**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## Implementieren von Antwort-Streaming in einer benutzerdefinierten Laufzeitumgebung
Für [Antwort-Streaming-Funktionen](configuration-response-streaming.md) haben die Endpunkte `response` und `error` ein leicht geändertes Verhalten, das es der Laufzeit ermöglicht, Teilantworten an den Client zu streamen und Nutzlasten in Paketen zurückzugeben. Weitere Informationen zu dem spezifischen Verhalten finden Sie unter:
+ `/runtime/invocation/AwsRequestId/response` – Gibt den `Content-Type`-Header von der Laufzeit zum Senden an den Client weiter. Lambda gibt die Nutzlasten der Antwort in Blöcken über HTTP/1.1-Blocktransfer-Codierungsschema zurück. Um die Antwort an Lambda zu streamen, muss die Laufzeit:
+ Den `Lambda-Runtime-Function-Response-Mode`-HTTP-Header auf `streaming` festlegen.
+ Legen Sie den `Transfer-Encoding`-Header auf `chunked` fest.
+ Die Antwort in Übereinstimmung mit der HTTP/1.1-Blocktransfer-Codierungsspezifikation schreiben.
+ Schließt die zugrunde liegende Verbindung, nachdem sie die Antwort erfolgreich geschrieben hat.
+ `/runtime/invocation/AwsRequestId/error` – Die Laufzeit kann diesen Endpunkt verwenden, um Funktions- oder Laufzeitfehler an Lambda zu melden, das auch den `Transfer-Encoding`-Header akzeptiert. Dieser Endpunkt kann nur aufgerufen werden, bevor die Laufzeit mit dem Senden einer Aufrufantwort beginnt.
+ Melden von Fehlern in der Mitte des Prozesses mit Hilfe von Fehler-Trailern in `/runtime/invocation/AwsRequestId/response` – Um Fehler zu melden, die auftreten, nachdem die Laufzeit mit dem Schreiben der Antwort auf den Aufruf begonnen hat, kann die Laufzeit optional HTTP-Trailing-Header namens `Lambda-Runtime-Function-Error-Type` und `Lambda-Runtime-Function-Error-Body` anfügen. Lambda behandelt dies als erfolgreiche Antwort und leitet die Fehler-Metadaten, die die Laufzeit bereitstellt, an den Client weiter.
**Anmerkung**
Um nachgestellte `Trailer`-Header anzufügen, muss die Laufzeit den Header-Wert am Anfang der HTTP-Anfrage festlegen. Dies ist eine Voraussetzung der HTTP/1.1-Blocktransfer-Codierungs-Spezifikation.
+ `Lambda-Runtime-Function-Error-Type` – Der Fehlertyp, auf den die Laufzeit gestoßen ist. Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, wir empfehlen jedoch ein Format von**. Beispiel, `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body` – Base64-kodierte Informationen über den Fehler.
## Erstellung benutzerdefinierter Laufzeiten für Lambda Managed Instances
Lambda Managed Instances verwenden dieselbe Runtime-API wie Lambda-Funktionen (Standard). Es gibt jedoch wesentliche Unterschiede darin, wie benutzerdefinierte Laufzeiten implementiert werden müssen, um das Modell der gleichzeitigen Ausführung von Managed Instances zu unterstützen.
### Gleichzeitige Bearbeitung von Anfragen
Der Hauptunterschied bei der Erstellung benutzerdefinierter Laufzeiten für verwaltete Instanzen ist die Unterstützung gleichzeitiger Aufrufe. Im Gegensatz zu Lambda-Funktionen (Standard), bei denen die Laufzeit jeweils einen Aufruf verarbeitet, können Managed Instances mehrere Aufrufe gleichzeitig innerhalb einer einzigen Ausführungsumgebung verarbeiten.
Ihre benutzerdefinierte Laufzeit muss:
+ **Support gleichzeitiger `/next` Anfragen** — Die Runtime kann mehrere gleichzeitige Aufrufe an die [nächste Aufruf-API](runtimes-api.md#runtimes-api-next) tätigen, bis zu dem in der `AWS_LAMBDA_MAX_CONCURRENCY` Umgebungsvariablen angegebenen Grenzwert.
+ **Gleichzeitige `/response` Anfragen verarbeiten** [— Bei mehreren Aufrufen kann die Aufruf-Antwort-API gleichzeitig aufgerufen werden.](runtimes-api.md#runtimes-api-response)
+ **Implementieren Sie eine threadsichere Bearbeitung von Anfragen** — Stellen Sie sicher, dass sich gleichzeitige Aufrufe nicht gegenseitig behindern, indem Sie gemeinsam genutzte Ressourcen und den Status ordnungsgemäß verwalten.
+ **Verwenden Sie eine eindeutige Anfrage IDs** — Verfolgen Sie jeden Aufruf separat, indem Sie den `Lambda-Runtime-Aws-Request-Id` Header verwenden, um Antworten den entsprechenden Anfragen zuzuordnen.
### Implementierungsmuster
Ein typisches Implementierungsmuster für Laufzeiten von Managed Instances beinhaltet die Erstellung von Worker-Threads oder Prozessen zur Verarbeitung gleichzeitiger Aufrufe:
1. **Das Parallelitätslimit auslesen** — Lesen Sie bei der Initialisierung die `AWS_LAMBDA_MAX_CONCURRENCY` Umgebungsvariable, um zu bestimmen, wie viele gleichzeitige Aufrufe unterstützt werden sollen.
1. **Worker-Pool erstellen** — Initialisieren Sie einen Worker-Pool (Threads, Prozesse oder asynchrone Aufgaben), der dem Parallelitätslimit entspricht.
1. **Worker-Verarbeitungsschleife** — Jeder Worker unabhängig:
+ Ruft `/runtime/invocation/next` auf, um ein Aufrufereignis abzurufen
+ Ruft den Funktionshandler mit den Ereignisdaten auf
+ Sendet die Antwort an `/runtime/invocation/AwsRequestId/response`
+ Wiederholt die Schleife
### Weitere Überlegungen
+ **Protokollierungsformat** — Verwaltete Instances unterstützen nur das JSON-Protokollformat. Stellen Sie sicher, dass Ihre Laufzeit die `AWS_LAMBDA_LOG_FORMAT` Umgebungsvariable respektiert und nur das JSON-Format verwendet. Weitere Informationen finden Sie unter [Konfiguration der JSON- und Klartext-Protokollformate](monitoring-cloudwatchlogs-logformat.md).
+ **Gemeinsam genutzte Ressourcen** — Seien Sie vorsichtig, wenn Sie gemeinsam genutzte Ressourcen wie das `/tmp` Verzeichnis mit gleichzeitigen Aufrufen verwenden. Implementieren Sie geeignete Schließmechanismen, um Rennbedingungen zu vermeiden.
Weitere Informationen zu Ausführungsumgebungen für Lambda Managed Instances finden Sie unter[Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances](lambda-managed-instances-execution-environment.md).
# Tutorial: Erstellen einer benutzerdefinierten Laufzeit
In diesem Tutorial erstellen Sie eine Lambda-Funktion mit einer benutzerdefinierten Laufzeit. Sie beginnen, indem Sie die Laufzeit in das Bereitstellungspaket der Funktion einfügen. Anschließend migrieren Sie sie zu einer Ebene, die Sie unabhängig von der Funktion verwalten. Schließlich geben Sie die Laufzeitebene frei, indem Sie ihre ressourcenbasierte Berechtigungsrichtlinie aktualisieren.
## Voraussetzungen
In diesem Tutorial wird davon ausgegangen, dass Sie über Kenntnisse zu den grundlegenden Lambda-Operationen und der Lambda-Konsole verfügen. Sofern noch nicht geschehen, befolgen Sie die Anweisungen unter [Erstellen einer Lambda-Funktion mit der Konsole](getting-started.md#getting-started-create-function), um Ihre erste Lambda-Funktion zu erstellen.
Um die folgenden Schritte durchzuführen, benötigen Sie die [AWS CLI Version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Befehle und die erwartete Ausgabe werden in separaten Blöcken aufgeführt:
```
aws --version
```
Die Ausgabe sollte folgendermaßen aussehen:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Bei langen Befehlen wird ein Escape-Zeichen (`\`) wird verwendet, um einen Befehl über mehrere Zeilen zu teilen.
Verwenden Sie auf Linux und macOS Ihren bevorzugten Shell- und Paket-Manager.
**Anmerkung**
In Windows werden einige Bash-CLI-Befehle, die Sie häufig mit Lambda verwenden (z. B. `zip`), von den integrierten Terminals des Betriebssystems nicht unterstützt. Um eine in Windows integrierte Version von Ubuntu und Bash zu erhalten, [installieren Sie das Windows-Subsystem für Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Die CLI-Beispielbefehle in diesem Handbuch verwenden die Linux-Formatierung. Befehle, die Inline-JSON-Dokumente enthalten, müssen neu formatiert werden, wenn Sie die Windows-CLI verwenden.
Sie benötigen eine IAM-Rolle, um eine Lambda Funktion zu erstellen. Die Rolle benötigt die Berechtigung zum Senden von Protokollen an CloudWatch Logs und zum Zugriff auf die AWS-Services, die Ihre Funktion verwendet. Wenn Sie nicht über eine Rolle für die Funktionserstellung verfügen, erstellen Sie jetzt eine.
**So erstellen Sie eine Ausführungsrolle**
1. Öffnen Sie die Seite [Roles (Rollen)](https://console.aws.amazon.com/iam/home#/roles) in der IAM-Konsole.
1. Wählen Sie **Create role** aus.
1. Erstellen Sie eine Rolle mit den folgenden Eigenschaften.
+ **Trusted entity (Vertrauenswürdige Entität)** – **Lambda**.
+ **Permissions (Berechtigungen)** – **AWSLambdaBasicExecutionRole**.
+ **Role name (Name der Rolle** – **lambda-role**.
Die Richtlinie **AWSLambdaBasicExecutionRole** verfügt über die Berechtigungen, die die Funktion zum Schreiben von Protokollen in CloudWatch Logs benötigt.
## Erstellen einer -Funktion
Erstellen Sie eine Lambda-Funktion mit einer benutzerdefinierten Laufzeit. Dieses Beispiel enthält zwei Dateien: eine `bootstrap`-Laufzeitdatei und einen Funktions-Handler. Beide sind in Bash implementiert.
1. Erstellen Sie ein Verzeichnis für das Projekt und wechseln Sie dann zu diesem Verzeichnis.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Erstellen Sie eine neue Datei mit dem Namen `bootstrap`. Dies ist die benutzerdefinierte Laufzeit.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
Die Laufzeit lädt ein Funktionsskript aus dem Bereitstellungspaket. Sie verwendet zwei Variablen, um das Skript zu finden. `LAMBDA_TASK_ROOT` gibt an, wohin das Paket extrahiert wurde, und `_HANDLER` enthält den Namen des Skripts.
Nachdem die Laufzeit das Funktionsskript geladen hat, verwendet sie die Laufzeit-API, um ein Aufrufereignis aus Lambda abzurufen, übergibt das Ereignis an den Handler und sendet die Antwort zurück an Lambda. Um die Anforderungs-ID abzurufen, speichert die Laufzeit die Header aus der API-Antwort in einer temporären Datei und liest den `Lambda-Runtime-Aws-Request-Id`-Header aus der Datei.
**Anmerkung**
Laufzeit besitzen zusätzliche Verantwortlichkeiten, darunter Fehlerbehandlung und Bereitstellung von Kontextinformationen für den Handler. Details hierzu finden Sie unter [Voraussetzungen](runtimes-custom.md#runtimes-custom-build).
1. Erstellen Sie ein Skript für die Funktion. Das folgende Beispielskript definiert eine Handler-Funktion, die Ereignisdaten annimmt, protokolliert sie in `stderr` und gibt sie zurück.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
Das `runtime-tutorial`-Verzeichnis sollte jetzt wie folgt aussehen:
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Konvertieren Sie die Dateien zu ausführbaren Dateien und fügen Sie sie einem ZIP-Dateiarchiv hinzu. Dies ist das Bereitstellungspaket.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Erstellen Sie eine Funktion mit dem Namen `bash-runtime`. Geben Sie für `--role` den ARN Ihrer Lambda-[Ausführungsrolle](lambda-intro-execution-role.md) ein.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Die Funktion aufrufen.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
Die **cli-binary-format**-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface-Benutzerhandbuch für Version 2*.
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Überprüfen Sie die Antwort.
```
cat response.txt
```
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
Echoing request: '{"text":"Hello"}'
```
## Erstellen einer Ebene
Um Laufzeitcode und Funktionscode voneinander zu trennen, erstellen Sie eine Ebene, die nur die Laufzeit enthält. Mit Ebenen können Sie die Abhängigkeiten Ihrer Funktion unabhängig entwickeln. Sie können darüber hinaus die Speichernutzung reduzieren, wenn Sie dieselbe Ebene für mehrere Funktionen verwenden. Weitere Informationen finden Sie unter [Verwaltung von Lambda-Abhängigkeiten mit Ebenen](chapter-layers.md).
1. Erstellen Sie eine ZIP-Datei, die die `bootstrap`-Datei enthält.
```
zip runtime.zip bootstrap
```
1. Erstellen Sie eine Ebene mit dem [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x)-Befehl.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
Hierdurch wird die erste Version der Ebene erstellt.
## Aktualisieren der Funktion
Um die Laufzeitebene in der Funktion zu verwenden, konfigurieren Sie die Funktion für die Verwendung der Ebene und entfernen den Laufzeitcode aus der Funktion.
1. Aktualisieren Sie die Konfiguration der Funktion, um die Ebene einzubeziehen.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Dadurch wird die Laufzeit zur Funktion im `/opt`-Verzeichnis hinzugefügt. Um sicherzustellen, dass Lambda die Laufzeit in der Ebene verwendet, müssen Sie die `boostrap`-Datei aus dem Bereitstellungspaket der Funktion entfernen, wie in den nächsten beiden Schritten gezeigt.
1. Erstellen Sie eine ZIP-Datei, die den Funktionscode enthält.
```
zip function-only.zip function.sh
```
1. Aktualisieren Sie den Funktionscode so, dass er nur das Handler-Skript enthält.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Rufen Sie die Funktion auf, um zu überprüfen, ob sie mit der Laufzeitebene funktioniert.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
Die **cli-binary-format**-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface-Benutzerhandbuch für Version 2*.
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Überprüfen Sie die Antwort.
```
cat response.txt
```
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
Echoing request: '{"text":"Hello"}'
```
## Aktualisieren der Laufzeit
1. Um Informationen zur Ausführungsumgebung zu protokollieren, aktualisieren Sie das Laufzeitskript, sodass es Umgebungsvariablen ausgibt.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Erstellen Sie eine ZIP-Datei mit der neuen Version der `bootstrap`-Datei.
```
zip runtime.zip bootstrap
```
1. Erstellt eine neue Version der `bash-runtime`-Ebene.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Konfigurieren Sie die Funktion für die Verwendung der neuen Version der Ebene.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Freigeben der Ebene
Um eine Ebene mit einem anderen AWS-Konto gemeinsam zu nutzen, fügen Sie der [ressourcenbasierten Richtlinie](access-control-resource-based.md) der Ebene eine kontenübergreifende Berechtigungsanweisung hinzu. Führen Sie den Befehl [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) aus und geben Sie die Konto-ID als `principal` an. In jeder Anweisung können Sie einem einzelnen Konto, allen Konten oder einer Organisation in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) eine Berechtigung erteilen.
Im folgenden Beispiel wird dem Konto 111122223333 Zugriff auf Version 2 der `bash-runtime`-Ebene gewährt.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Die Ausgabe sollte folgendermaßen oder ähnlich aussehen:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Berechtigungen gelten nur für eine Version mit einer Ebene. Wiederholen Sie den Vorgang bei jeder Erstellung einer neuen Ebenenversion.
## Bereinigen
Löschen Sie alle Versionen der Ebene.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Da die Funktion einen Verweis auf Version 2 der Ebene enthält, ist diese nach wie vor in Lambda vorhanden. Die Funktion funktioniert weiter. Es können jedoch keine weiteren Funktionen für die Verwendung der gelöschten Version konfiguriert werden. Wenn Sie die Liste der Ebenen in der Funktion ändern, müssen Sie eine neue Version angeben oder die gelöschte Ebene auslassen.
Löschen Sie die Funktion mit dem Befehl [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```
# Open-Source-Repositorys
AWS Lambda bietet eine Vielzahl von Open-Source-Tools, -Bibliotheken und -Komponenten, mit denen Sie Ihre serverlosen Anwendungen erstellen, anpassen und optimieren können. Zu diesen Ressourcen gehören Runtime-Interface-Clients, Ereignisbibliotheken, Container-Basis-Images, Entwicklungstools und Beispielprojekte, die von verwaltet werden AWS und auf GitHub dieser verfügbar sind. Durch die Nutzung dieser Open-Source-Repositorys können Sie die Funktionen von Lambda erweitern, benutzerdefinierte Laufzeiten erstellen, Ereignisse aus verschiedenen AWS Diensten verarbeiten und tiefere Einblicke in die Leistung Ihrer Funktion gewinnen. Diese Seite bietet einen Überblick über die wichtigsten Open-Source-Projekte, die die Lambda-Entwicklung unterstützen.
## Laufzeit-Schnittstellenclients
Lambda Runtime Interface Clients (RICs) sind Open-Source-Bibliotheken, die die [Runtime-API](runtimes-api.md) implementieren und die Interaktion zwischen Ihrem Funktionscode und dem Lambda-Service verwalten. Diese Clients übernehmen den Empfang von Aufrufereignissen, die Weitergabe von Kontextinformationen und die Meldung von Fehlern.
Die von den verwalteten Laufzeiten und Container-Basisimages von Lambda verwendeten Laufzeit-Schnittstellenclients werden als Open Source veröffentlicht. Wenn Sie benutzerdefinierte Laufzeiten erstellen oder bestehende erweitern, können Sie diese Open-Source-Bibliotheken verwenden, um Ihre Implementierung zu vereinfachen. Die folgenden GitHub Open-Source-Repositorys enthalten den Quellcode für Lambdas: RICs
+ [Node.js-Laufzeit-Schnittstellenclient](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client)
+ [Python-Laufzeit-Schnittstellenclient](https://github.com/aws/aws-lambda-python-runtime-interface-client)
+ [Java-Laufzeit-Schnittstellenclient](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client)
+ [Ruby-Laufzeit-Schnittstellenclient](https://github.com/aws/aws-lambda-ruby-runtime-interface-client)
+ [.NET-Laufzeit-Schnittstellenclient](https://github.com/aws/aws-lambda-dotnet)
+ [Rust-Runtime-Schnittstellenclient](https://github.com/aws/aws-lambda-rust-runtime)
+ [Go-Laufzeit-Schnittstellenclient](https://github.com/aws/aws-lambda-go)
+ [Swift Runtime Interface-Client](https://github.com/awslabs/swift-aws-lambda-runtime) (experimentell)
+ [C\$1\$1-Laufzeitschnittstellenclient](https://github.com/awslabs/aws-lambda-cpp) (experimentell)
+ [Lambda-Basis-Images](https://github.com/aws/aws-lambda-base-images)
Weitere Informationen zur Verwendung dieser Clients zum Erstellen benutzerdefinierter Laufzeiten finden Sie unter [Erstellen einer benutzerdefinierten Laufzeit für AWS Lambda](runtimes-custom.md).
## Ereignisbibliotheken
Lambda-Ereignisbibliotheken bieten Typdefinitionen und Hilfsprogramme für die Verarbeitung von Ereignissen aus verschiedenen AWS Diensten. Diese Bibliotheken unterstützen Sie beim Parsen und Verarbeiten von Ereignisdaten auf typsichere Weise, wodurch die Arbeit mit Ereignissen aus Services wie Amazon S3, Amazon DynamoDB und Amazon API Gateway vereinfacht wird.
AWS Stellt für kompilierte Sprachen die folgenden Ereignisbibliotheken bereit:
+ [Java-Ereignisbibliothek](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)
+ [.NET-Ereignisbibliotheken](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src)
+ [Go-Ereignisbibliothek](https://github.com/aws/aws-lambda-go/tree/main/events)
+ [Rust-Ereignisbibliothek](https://github.com/awslabs/aws-lambda-rust-runtime)
Für interpretierte Sprachen wie Node.js, Python und Ruby können Ereignisse direkt als JSON-Objekte geparst werden, ohne dass eine separate Bibliothek erforderlich ist. Entwickler, die Node.js und Python verwenden, können jedoch Powertools for nutzen AWS Lambda, das integrierte Schemas für AWS Ereignisse bereitstellt, die Typhinweise, Datenvalidierung und Funktionen bieten, die denen von kompilierten Sprachbibliotheken ähneln.
+ [Powertools für TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas)
+ [Powertools für Python](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models)
## Container-Basisimages
AWS stellt Open-Source-Container-Basis-Images bereit, die Sie als Ausgangspunkt für die Erstellung von Container-Images für Ihre Lambda-Funktionen verwenden können. Diese Basisimages enthalten den Laufzeit-Schnittstellenclient und andere Komponenten, die zum Ausführen Ihrer Funktionen in der Lambda-Ausführungsumgebung erforderlich sind.
Weitere Informationen zu den verfügbaren Basisimages und deren Verwendung finden Sie im Repository für [AWS -Basisimages](https://github.com/aws/aws-lambda-base-images) sowie unter [Erstellen einer Lambda-Funktion mit einem Container-Image](images-create.md).
## Entwicklungstools
AWS bietet zusätzliche Open-Source-Entwicklungstools, mit denen Sie Ihre Lambda-Funktionen erstellen und optimieren können:
### Powertools für AWS Lambda
Powertools for AWS Lambda vereinfacht die serverlose Entwicklung mit wichtigen Hilfsprogrammen zur Vermeidung doppelter Verarbeitung, Stapelverarbeitung für die Verarbeitung mehrerer Datensätze und Kafka-Benutzerbibliothek. Diese Funktionen helfen Ihnen, die Komplexität des Codes und den Betriebsaufwand zu minimieren.
Sie können auch die integrierte Ereignisschemavalidierung, die strukturierte Protokollierung und Ablaufverfolgung sowie die Integration von Parameterspeichern nutzen, die darauf ausgelegt sind, die Erstellung produktionsreifer Lambda-Funktionen zu beschleunigen und gleichzeitig gut konzipierte Best Practices zu befolgen AWS .
GitHub Repositorien:
+ [Python](https://github.com/aws-powertools/powertools-lambda-python)
+ [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript)
+ [Java](https://github.com/aws-powertools/powertools-lambda-java)
+ [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet)
### Java-Entwicklungstools
+ [Java Profiler (experimentell)](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler) – Ein Tool zur Profilerstellung für Java-Lambda-Funktionen.
+ [Java-Bibliotheken](https://github.com/aws/aws-lambda-java-libs) — Ein Repository, das eine umfassende Sammlung von Java-Bibliotheken und -Tools für die Lambda-Entwicklung enthält, einschließlich wichtiger Projekte wie JUnit Testdienstprogramme und Profilierungstools.
+ [Serverless-Java-Container](https://github.com/aws/serverless-java-container) – Eine Bibliothek, mit der Sie vorhandene Java-Anwendungen mit minimalen Änderungen in Lambda ausführen können.
### .NET-Entwicklungstools
[AWS Lambda Das.NET-Repository](https://github.com/aws/aws-lambda-dotnet) stellt .NET-Bibliotheken und Tools für die Lambda-Entwicklung bereit, einschließlich wichtiger Projekte wie AWS Lambda Tools für die .NET CLI und .NET Core-Server zum Hosten von.NET Core-Anwendungen.
## Beispielprojekte
Erkunden Sie eine umfassende Sammlung von Beispielprojekten und -anwendungen für Lambda in den [Serverless-Land-Repositorys](https://serverlessland.com/repos). Diese Beispiele veranschaulichen verschiedene Anwendungsfälle, Integrationsmuster und bewährte Verfahren für Lambda, die Ihnen den Einstieg in Ihre Serverless-Anwendungen erleichtern.