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. nodejs22.x oder python3.13. Um eine Funktion für die Verwendung einer neuen Hauptsprachversion zu konfigurieren, müssen Sie die Laufzeitkennung ändern. Da AWS Lambda keine Abwärtskompatibilität zwischen Hauptversionen garantieren kann, ist dies ein kundengesteuerter Vorgang.
Bei einer Funktion, die als Container-Image definiert ist, 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. Die Laufzeit ist mit einer der Amazon Linux-Distributionen gepaart. Die zugrunde liegende Ausführungsumgebung bietet zusätzliche Bibliotheken und Umgebungsvariablen, auf die Sie über Ihren Funktionscode zugreifen können.
Lambda ruft Ihre Funktion in einer Ausführungsumgebung 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 oder Rust, verwenden Sie eine reine OS-Laufzeit. Die Lambda-Ausführungsumgebung bietet eine Laufzeitschnittstelle zum Abrufen von Aufrufereignissen und Senden von Antworten. Sie können andere Sprachen bereitstellen, indem Sie zusammen mit Ihrem Funktionscode oder in einem Layer eine benutzerdefinierte Laufzeit 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. Die Tabelle enthält die aktuell angenommenen Ablaufdaten für die Laufzeit, basierend auf unserer Richtlinie für den Laufzeitablauf. Diese Daten dienen zu Planungszwecken und können sich ändern.
| Name | ID | Betriebssystem | Datum der Veraltung | Blockfunktion erstellen | Blockfunktion aktualisieren |
|---|---|---|---|---|---|
|
Node.js 22 |
|
Amazon Linux 2023 |
30. Apr 2027 |
1. Juni 2027 |
1. Juli 2027 |
|
Node.js 20 |
|
Amazon Linux 2023 |
30. Apr 2026 |
1. Juni 2026 |
1. Juli 2026 |
|
Python 3.13 |
|
Amazon Linux 2023 |
30. Juni 2029 |
31. Juli 2029 |
31. August 2029 |
|
Python 3.12 |
|
Amazon Linux 2023 |
31. Oktober 2028 |
30. November 2028 |
10. Januar 2029 |
|
Python 3.11 |
|
Amazon Linux 2 |
30. Juni 2026 |
31. Juli 2026 |
31. August 2026 |
|
Python 3.10 |
|
Amazon Linux 2 |
30. Juni 2026 |
31. Juli 2026 |
31. August 2026 |
|
Python 3.9 |
|
Amazon Linux 2 |
15. Dezember 2025 |
3. Februar 2026 |
9. März 2026 |
|
Java 21 |
|
Amazon Linux 2023 |
30. Juni 2029 |
31. Juli 2029 |
31. August 2029 |
|
Java 17 |
|
Amazon Linux 2 |
30. Juni 2026 |
31. Juli 2026 |
31. August 2026 |
|
Java 11 |
|
Amazon Linux 2 |
30. Juni 2026 |
31. Juli 2026 |
31. August 2026 |
|
Java 8 |
|
Amazon Linux 2 |
30. Juni 2026 |
31. Juli 2026 |
31. August 2026 |
|
.NET 9 (nur Container) |
|
Amazon Linux 2023 |
Nicht geplant |
Nicht geplant |
Nicht geplant |
|
.NET 8 |
|
Amazon Linux 2023 |
10. November 2026 |
10. Dezember 2026 |
11. Januar 2027 |
|
Ruby 3.4 |
|
Amazon Linux 2023 |
Nicht geplant |
Nicht geplant |
Nicht geplant |
|
Ruby 3.3 |
|
Amazon Linux 2023 |
31. März 2027 |
30. Apr 2027 |
31. Mai 2027 |
|
Ruby 3.2 |
|
Amazon Linux 2 |
31. März 2026 |
30. Apr 2026 |
31. Mai 2026 |
|
Reine OS-Laufzeit |
|
Amazon Linux 2023 |
30. Juni 2029 |
31. Juli 2029 |
31. August 2029 |
|
Reine OS-Laufzeit |
|
Amazon Linux 2 |
30. Juni 2026 |
31. Juli 2026 |
31. August 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.
Um programmgesteuert mit anderen AWS-Services und Ressourcen aus Ihrer Lambda-Funktion zu interagieren, können Sie eines der AWS-SDKs verwenden. Die Laufzeiten von Node.js, Python und Ruby enthalten eine Version des AWS-SDKs. Um jedoch die volle Kontrolle über Ihre Abhängigkeiten zu behalten und die Abwärtskompatibilität 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 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. Beispielsweise ist das der Fall, 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 AWS-SDKs, die in den Laufzeiten von Node.js, Python und Ruby enthalten sind. Informationen darüber, welche Version des AWS-SDKs in der von Ihnen verwendeten Laufzeit enthalten ist, finden Sie in den folgenden Abschnitten:
Lambda unterstützt weiterhin die Programmiersprache Go, auch nachdem die Go 1.x-Laufzeit veraltet ist. Weitere Informationen finden Sie im AWS Compute Blog unter Migrating AWS Lambda functions from the Go1.x runtime to the custom runtime on Amazon Linux 2
Alle unterstützten Lambda-Laufzeiten unterstützen sowohl x86_64- 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
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.
-
Java 25 – November 2025
-
Python 3.14 – November 2025
-
Node.js 24 – November 2025
-
.NET 10 – Januar 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.
Nachdem eine Laufzeitumgebung veraltet ist, kann AWS keine Sicherheitspatches oder Updates mehr auf diese Laufzeitumgebung anwenden und Funktionen, die diese Laufzeitumgebung 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 Laufzeit-Upgrades und veralteten Versionen finden Sie in den folgenden Abschnitten und unter Managing AWS Lambda runtime upgrades
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 übergreifenden Verantwortlichkeit
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. 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). |
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 |
Benachrichtigung der Kunden vor der Abschaffung der Laufzeit über Dokumentation, AWS Health Dashboard, E-Mail und Trusted Advisor. Die Verantwortung für Laufzeit-Updates endet mit dem Zeitpunkt, an dem sie veraltet sind. |
Überwachen Sie die Lambda-Dokumentation, AWS Health Dashboard, E-Mail oder Trusted Advisor auf Informationen zur Laufzeitveralterung. 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
Nachdem eine Laufzeitumgebung veraltet ist, kann AWS keine Sicherheitspatches oder Updates mehr auf diese Laufzeitumgebung anwenden und Funktionen, die diese Laufzeitumgebung verwenden, haben keinen Anspruch mehr auf technischen Support. Sie können Ihre Funktionen zwar auf unbestimmte Zeit weiter aufrufen, AWS empfiehlt jedoch dringend, zu einer unterstützten Laufzeit 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 Funktionsversionen und Aliasnamen, 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 |
|
|
Ablehnung |
Datum der Veraltung |
|
|
Blockfunktion erstellen |
Mindestens 30 Tage nach der Einstellung |
|
|
Blockfunktion aktualisieren |
Mindestens 60 Tage nach der Einstellung |
|
Anmerkung
Für einige Laufzeiten verzögert AWS die Termine für das Erstellen und Aktualisieren von Blockfunktionen über die üblichen 30 bzw. 60 Tage nach der Veralterung hinaus. AWS hat diese Änderung als Reaktion auf Kundenrückmeldungen vorgenommen, um Ihnen mehr Zeit für die Aktualisierung Ihrer Funktionen zu geben. In den Tabellen in Unterstützte Laufzeiten und Veraltete Laufzeitumgebungen 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 Ihrem AWS-Konto diese Laufzeit verwenden. Benachrichtigungen werden auch in AWS Health Dashboard und AWS Trusted Advisor angezeigt.
-
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 $LATEST-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.
Lambda sendet eine E-Mail-Benachrichtigung an den primären Kontokontakt Ihres AWS-Konto. Informationen zum Anzeigen oder Aktualisieren der E-Mail-Adressen in Ihrem Konto finden Sie in der allgemeinen AWS-Referenz unter Updating contact information.
-
Empfangen von Benachrichtigungen über AWS Health Dashboard:
AWS Health Dashboard zeigt mindestens 180 Tage, bevor eine Laufzeit veraltet ist, eine Benachrichtigung an. Benachrichtigungen werden auf der Seite Ihr Kontostatus unter Andere Benachrichtigungen
angezeigt. Auf der Registerkarte Betroffene Ressourcen in der Benachrichtigung sind die $LATEST-Versionen aller Funktionen aufgeführt, die die Laufzeit verwenden. Anmerkung
Eine vollständige und aktuelle Liste der betroffenen Funktionsversionen finden Sie unter Trusted Advisor oder Rufen Sie Daten über Lambda-Funktionen ab, die eine veraltete Laufzeit verwenden.
AWS Health Dashboard-Benachrichtigungen laufen 90 Tage ab, nachdem die betroffene Laufzeit veraltet ist.
-
Verwenden von AWS Trusted Advisor
Trusted Advisor zeigt mindestens 180 Tage, bevor eine Laufzeit veraltet ist, eine Benachrichtigung an. Benachrichtigungen werden auf der Seite Sicherheit
angezeigt. Eine Liste der betroffenen Funktionen wird unter AWS Lambda-Funktionen, die veraltete Laufzeiten verwenden angezeigt. Diese Liste von Funktionen zeigt sowohl die $LATEST als auch veröffentlichte Versionen und wird automatisch aktualisiert, um den aktuellen Status Ihrer Funktionen widerzuspiegeln. Sie können wöchentliche E-Mail-Benachrichtigungen von Trusted Advisor auf der Seite Einstellungen
in 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 |
|---|---|---|---|---|---|
|
Node.js 18 |
nodejs18.x
|
Amazon Linux 2 |
1. Sept. 2025 |
3. Februar 2026 |
9. März 2026 |
|
.NET 6 |
dotnet6
|
Amazon Linux 2 |
20. Dezember 2024 |
3. Februar 2026 |
9. März 2026 |
|
Python 3.8 |
python3.8
|
Amazon Linux 2 |
14. Oktober 2024 |
3. Februar 2026 |
9. März 2026 |
|
Node.js 16 |
nodejs16.x
|
Amazon Linux 2 |
12. Juni 2024 |
3. Februar 2026 |
9. März 2026 |
|
.NET 7 (nur Container) |
dotnet7
|
Amazon Linux 2 |
14. Mai 2024 |
N/A |
N/A |
|
Java 8 |
java8
|
Amazon Linux |
8. Januar 2024 |
8. Februar 2024 |
9. März 2026 |
|
Go 1.x |
go1.x
|
Amazon Linux |
8. Januar 2024 |
8. Februar 2024 |
9. März 2026 |
|
Reine OS-Laufzeit |
provided
|
Amazon Linux |
8. Januar 2024 |
8. Februar 2024 |
9. März 2026 |
|
Ruby 2.7 |
ruby2.7
|
Amazon Linux 2 |
7. Dezember 2023 |
9. Januar 2024 |
9. März 2026 |
|
Node.js 14 |
nodejs14.x
|
Amazon Linux 2 |
4. Dezember 2023 |
9. Januar 2024 |
9. März 2026 |
|
Python 3.7 |
python3.7
|
Amazon Linux |
4. Dezember 2023 |
9. Januar 2024 |
9. März 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 |
N/A |
N/A |
|
.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. Sept. 2016 |
31. Oktober 2016 |
In den meisten Fällen ist das Ende der Nutzungsdauer einer Sprachversion oder eines Betriebssystems weit im Voraus bekannt. Die folgenden Links enthalten Zeitpläne für das Ende der Lebensdauer 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
-
Python – devguide.python.org
-
Ruby – www.ruby-lang.org
-
Java – www.oracle.com
and Corretto FAQs -
Go – golang.org
-
.NET – dotnet.microsoft.com
