Lambda gibt Node.js 26 und Python 3.15 ein Testfenster

AWS legt die Runtime-Prüfung vor den GA-Termin

AWS hat Node.js 26 und Python 3.15 am 25. August 2026 als verwaltete Lambda-Runtimes in eine Public Preview gestellt. Der AWS-Beitrag zur Ankündigung ist in einem Punkt angenehm klar: Beide Laufzeiten sind ein Testangebot vor der allgemeinen Verfügbarkeit. Für Teams mit gepflegten Funktionen ist das kein Anlass, eine Versionsnummer in jedes Manifest zu schieben. Es ist ein Zeitfenster, um den eigenen Build, die Imports und die Bereitstellungskette unter einer kommenden Runtime anzufassen.

Bis zu dieser Änderung veröffentlichte AWS verwaltete Lambda-Runtimes direkt als GA-Release. Weil sie dann unmittelbar für produktive Workloads bereitstanden, konnte das Lambda-Team nach eigener Darstellung keine Änderungen mehr vornehmen, die bestehende Funktionen beeinträchtigen. Die Preview verschiebt die unbequeme Arbeit nach vorne. Das ist technisch sinnvoll: Ein Fehler in einem nativen Add-on, einem Wheel oder einem Template fällt besser auf, solange der Runtime-Wechsel noch nicht zum Termindruck geworden ist.

Damit entsteht keine Pflicht, jede Funktion sofort zu klonen. Beginnen Sie bei den Kandidaten, die viele Abhängigkeiten, ein ungewöhnliches Build-Artefakt oder mehrere Infrastructure-as-Code-Schichten haben. Eine kleine API ohne Fremdmodule liefert schnell ein Basissignal. Eine Funktion mit Bildverarbeitung, kryptografischen Bibliotheken oder eigenen Layers zeigt dagegen eher, ob der tatsächliche Betrieb an einer stillen Annahme hängt. Das ist die Sorte Arbeit, die Wartbarkeit erzeugt: klein anfangen, Befunde notieren, dann die nächste Schicht nehmen.

Node.js 26 und Python 3.15 erreichen mehr als die Konsole

AWS nennt die Runtime-Identifier ausdrücklich: nodejs26.x für Node.js 26 und python3.15 für Python 3.15. Sie lassen sich in der Lambda-Konsole wählen und laut AWS ebenso über AWS CLI, CloudFormation, AWS SAM und AWS CDK festlegen. Suchen Sie deshalb nicht nur in einer Datei nach dem Runtime-Feld. Ein Identifier kann in einem CDK-Konstrukt, einem SAM-Template, einem Skript und einem Beispielservice auftauchen. Vier Fundstellen mit drei alten Namen sind kein Migrationsplan.

Bei Python gehört der Paketbau in denselben Test wie der Handler. Ein Deployment kann sauber durchlaufen und erst beim Import scheitern, wenn ein Paket nicht zur Laufzeitumgebung passt. Node.js hat die gleiche Klasse von Problemen bei gebündelten oder nativen Add-ons. AWS liefert keine Liste problematischer Bibliotheken. Das ist kein Mangel der Ankündigung, sondern eine Grenze ihrer Aussage. Sie sollten deshalb genau den Code ausführen, der die eigenen Imports, Serialisierung und externe Clients tatsächlich berührt.

Ein brauchbarer Testdatensatz muss keine Kopie realer Kundenvorgänge sein. Definierte Ereignisse mit erwartbaren Antworten reichen, wenn sie die relevanten Pfade auslösen. Notieren Sie dazu Runtime-Identifier, Commit oder Artefakt-Hash, Region, Deployment-Werkzeug und Ergebnis. Diese fünf Angaben machen eine Fehlermeldung reproduzierbar. Ohne sie wird aus einem Runtime-Problem rasch eine Suche nach dem letzten Menschen, der etwas im Repository angefasst hat.

Prüfen Sie auch die unspektakulären Nebenwege. Viele Lambda-Funktionen werden nicht nur durch einen Handler definiert, sondern durch Environment-Variablen, Layers, Code-Signing, Event-Quellen und kleine Hilfsskripte im Repository. Nicht jeder dieser Bausteine ist runtime-sensitiv. Genau deshalb lohnt eine Liste der berührten Komponenten statt eines großen Sammeltests. Wenn eine Funktion nur mit einem bestimmten Layer läuft, wird das sichtbar. Wenn ein Template den Identifier korrekt durchreicht, ist auch das ein verwertbarer Befund. So bleibt der Test auf die Abhängigkeiten gerichtet, die später tatsächlich gepflegt werden müssen. Erstellen Sie daraus eine kurze Tabelle mit Komponente, geprüftem Pfad, Ergebnis und Verantwortlichem; mehr Dokumentation braucht dieser kontrollierte erste Durchlauf für das Team zunächst noch nicht.

Tooling muss denselben Weg wie der spätere Rollout gehen

AWS schreibt, dass Drittanbieter für Observability, Infrastructure as Code und Deployment-Frameworks die Preview zur Kompatibilitätsprüfung nutzen können. Das ist der Hinweis, den man nicht überspringen sollte. Eine Funktion kann unter nodejs26.x laufen und trotzdem am Werkzeug davor hängen: ein Linter akzeptiert den Namen nicht, ein Konstrukt erzeugt ein altes Feld, ein Deployment-Plugin packt ein unpassendes Artefakt. Ein Konsolentest allein deckt diese Kette nicht ab.

Nehmen Sie die gleiche Pipeline, die Sie bei einem späteren Runtime-Wechsel einsetzen würden, und leiten Sie sie auf eine isolierte Funktion. Dann zeigt der Test, ob Templates, Rollen, Packaging und Monitoring miteinander funktionieren. Der interne Beitrag zu Preview-Funktionen und ihrer Governance ergänzt diesen Blick: Vorabversionen brauchen einen benannten Besitzer, der Fehler bewertet und einen Rückweg freigibt. Ein grüner Einzeltest ersetzt diese Zuständigkeit nicht.

Bei einem Fehler lohnt sich ein kleines Minimalbeispiel. Halten Sie die Eingabe, den erwarteten Ablauf, das beobachtete Verhalten und die verwendete Toolversion fest. AWS bittet Kunden, Partner und die Communities der Upstream-Sprachen ausdrücklich um Rückmeldungen vor GA. Ein nachvollziehbarer Befund hilft dabei; eine pauschale Meldung, die neue Runtime sei kaputt, produziert vor allem Rückfragen. Nebenbei bleibt das Minimalbeispiel intern nützlich, falls eine neue Preview-Revision den Fehler verändert.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptAt late afternoon in a compact home living room, one platform engineer places two different colored pebble sets into separate open bowls beside a small green plant. No documents, paper, maps, folders, notebooks, cards, labels, text, logos, or markings are present anywhere. No screens, monitors, devices, dashboards, interfaces, diagrams, server rooms, laboratories, factories, or industrial equipment appear in the scene. The intimate domestic setting and the separate bowls convey a careful compatibility trial before wider use. Photorealistic magazine photography in a wide 16:9 composition, with clean blank surfaces and no watermark, signature, blur, distortion, or deformation.

Breaking Changes bleiben vor GA möglich

AWS erlaubt während der Preview Breaking Changes und beschreibt genau das als Grund, Workloads vor GA zu testen und Probleme zu melden. Diese Ansage zieht eine klare technische Grenze. Eine Preview-Funktion sollte keine produktive Ereigniskette öffnen, keine unkontrollierten Schreibvorgänge ausführen und keine Berechtigungen erben, die sie nicht braucht. Isolierung ist hier kein bürokratischer Zusatz, sondern die Voraussetzung dafür, dass ein Test auch dann harmlos bleibt, wenn sich Verhalten oder Kompatibilität ändern.

Der robuste Ablauf ist wiederholbar, nicht heroisch. Legen Sie eine Testfunktion mit derselben Build- und Deployment-Kette an, führen Sie fest definierte Ereignisse aus und prüfen Sie bei jedem erneuten Lauf Imports, Initialisierung, Handler und die wesentlichen Logsignale. Wenn ein Befund entsteht, gehören Zeitpunkt, Artefakt und Reproduktionsschritte dazu. Damit lässt sich die Änderung eingrenzen, ohne eine Runtime-Ankündigung mit Vermutungen über die ganze Anwendung aufzuladen.

Der vorhandene Bildblock sitzt sinnvoll an dieser Stelle: Er verknüpft die getrennten Testpfade mit der Überschrift, unter der AWS mögliche Inkompatibilitäten benennt. Planen Sie außerdem den Rückweg. Ein Test muss wieder auf den bisher verwendeten Identifier gestellt werden können, und jemand sollte diese Änderung ausführen dürfen. Das ist kein großes Verfahren. Ein kurzer, getesteter Rückschritt bewahrt einen Preview-Lauf davor, versehentlich in den normalen Release-Betrieb zu rutschen.

SLA, Support und automatische GA-Übernahme passen nicht zusammen

AWS schließt die Preview-Runtimes vom Lambda SLA und von AWS Technical Support Plänen aus. Das Unternehmen rät außerdem davon ab, sie für Produktionsworkloads einzusetzen. Diese Kombination lässt wenig Raum für kreative Auslegung. Wer Verfügbarkeit zusagt oder einen Kundendienstprozess absichern muss, hält die Preview außerhalb dieses Pfads. Die neue Runtime darf wichtig sein, sie ist aber noch nicht die Runtime, auf der Sie verbindliche Betriebsannahmen aufbauen.

Gleichzeitig verwendet AWS für Preview und späteres GA denselben Runtime-Identifier. Funktionen wechseln nach AWS-Angabe beim GA-Release ohne Aktion des Kunden in den GA-Zustand. Das reduziert späteren Umstellungsaufwand, beweist aber nicht, dass der eigene Code bereit ist. Ein unveränderter Name kann nur den Wechselmechanismus vereinfachen. Er sagt nichts darüber, ob ein Layer, ein Monitoring-Agent oder ein selten genutzter Fehlerpfad unter der finalen Umgebung sauber arbeitet.

Setzen Sie darum einen Wiedervorlagetermin für die Preview-Funktionen. Vor GA lohnt ein kurzer Abgleich: Welche Funktionen nutzen noch den Identifier, welche Tests sind dokumentiert, welche offenen Befunde bleiben? So fällt der automatische Übergang nicht in eine vergessene Ecke des Accounts. Der Aufwand ist klein, die Wirkung nüchtern: Das Team weiß, ob es einen getesteten Kandidaten besitzt oder bloß eine Funktion, die irgendwann einmal in einer Vorabversion lief.

Für einen Linux-nahen Betrieb ist noch ein Detail wichtig: Trennen Sie den Befund der Lambda-Runtime vom Verhalten Ihrer lokalen Entwicklungsumgebung. Ein Container, ein WSL-Setup oder ein Build-Image kann ein Problem sichtbar machen, aber er ist nicht automatisch die Ausführungsumgebung von Lambda. Dokumentieren Sie daher, wo der Fehler auftritt und welches Artefakt tatsächlich hochgeladen wurde. Das verhindert zwei typische Fehlwege: eine lokale Reparatur, die im Cloud-Artefakt nie ankommt, und eine Cloud-Anpassung, die nur ein Abbildproblem des eigenen Rechners kaschiert. Präzise Grenzen sparen hier mehr Zeit als ein möglichst großer Testaufbau.

Regionen, Kosten und der kleine Prüfpfad

AWS bietet die beiden Preview-Runtimes laut Ankündigung in allen kommerziellen AWS-Regionen sowie in AWS GovCloud (US) und China-Regionen an. Das ersetzt keinen Test mit den eigenen Accounts, Rollen und Organisationsrichtlinien. Es nimmt aber eine häufige Ausrede vom Tisch: Für die genannten AWS-Umgebungen muss ein Team nicht auf eine gesonderte Regionalfreigabe warten. Wenn ein Zugriff fehlt, ist das ein konkreter Konfigurationsbefund und kein Urteil über Node.js 26 oder Python 3.15.

Zusätzliche Gebühren für die Preview nennt AWS nicht; Funktionen mit diesen Runtimes werden zu regulären Lambda-Tarifen berechnet. Daraus folgt keine Kostenzusage für Ihre Anwendung. Speicher, Dauer, Aufrufzahl und angeschlossene Services bleiben die üblichen Treiber. Für einen engen Test reicht meist ein begrenztes Volumen mit klaren Alarmgrenzen. Das ist hilfreicher als eine Sparrechnung, die aus einer Ankündigung mehr ableitet, als sie hergibt.

Der Prüfpfad lässt sich knapp halten: Identifier setzen, Artefakt mit der üblichen Kette bauen, relevante Handler ausführen, Deployment- und Observability-Werkzeuge prüfen, Ergebnis festhalten. Der interne Beitrag zum sicheren Testen von WASI-Modulen im Editor erinnert dabei an eine einfache Regel: Tooling und Ausführung verdienen getrennte Befunde. Wenn dieser Lauf grün bleibt, haben Sie keine allgemeine Qualitätsnote für eine Sprache gewonnen. Sie haben etwas Besseres: einen belastbaren Befund für Ihren eigenen Workload.