Mit der Ankündigung von AWS ab dem 1. August 2025 die INIT-Phase bei AWS Lambda standardisiert abzurechnen, steht eine wichtige Neuerung für Serverless-Entwickler an. AWS Lambda vereinfacht damit sein Abrechnungsmodell, insbesondere für Funktionen, die mit ZIP-Archiv-Paketen und verwalteten Laufzeiten betrieben werden. Bisher war die Zeit, die während der INIT-Phase bei Kaltstarts benötigt wurde, in diesen Fällen nicht in der Abrechnung enthalten. Die neue Regelung integriert nun sämtliche INIT-Phasen-Dauern in die Kostenberechnung, unabhängig von Paketierungsart oder Laufzeit.
Das hat insbesondere für On-Demand-Invokationen Bedeutung und beeinflusst die Kostenkalkulation nachhaltig, auch wenn der Effekt für die meisten Nutzer moderat ausfallen dürfte, da Kaltstarts selten vorkommen. Die Lambda-Funktion durchläuft in ihrem Lebenszyklus drei Hauptphasen, die INIT, INVOKE und SHUTDOWN genannt werden. Die INIT-Phase stellt den Initialisierungsschritt dar, der bei Kaltstarts aktiviert wird. Hierbei wird eine neue Ausführungsumgebung vorbereitet, die den Code und sämtliche Ressourcen der Funktion bereitstellt. Nach erfolgter Initialisierung folgt der INVOKE-Schritt, in dem der Funktionscode ausgeführt wird, um die eigentliche Aufgabe zu erledigen.
Abschließend erfolgt der SHUTDOWN-Prozess, bei dem die Ressourcen der Umgebung freigegeben werden, falls keine weitere Anfrage bearbeitet wird. Die INIT-Phase selbst ist ein komplexer Vorgang, der in maximal zehn Sekunden ablaufen kann. Dabei zieht Lambda den Funktionscode aus internen Amazon S3 Buckets oder von Amazon Elastic Container Registry (Amazon ECR), falls Container als Bereitstellungsmethode verwendet werden. Danach wird die Umgebung mit der zugewiesenen Speichergröße, der Laufzeit und weiteren Konfigurationen erstellt. Im Anschluss werden vier wesentliche Schritte in Folge ausgeführt: Zunächst werden Erweiterungen (Extensions) initialisiert.
Dann erfolgt das Bootstrap der Laufzeitumgebung, also die Bereitstellung der Laufzeit selbst. Darauf folgt die Ausführung des statischen Codes der Funktion und schließlich werden – sofern aktiviert – vorab definierte Laufzeithooks wie bei Lambda SnapStart ausgeführt. Bislang wurden die Kosten für die INIT-Phase bei auf Verwaltungslaufzeiten und ZIP-Paketierung basierenden Funktionen nicht berechnet. Im Gegensatz dazu galten bei kundenspezifischen Laufzeiten, durch Provisioned Concurrency oder bei Nutzung von Container-Paketen bereits Gebühren für die Initialisierungszeit. Mit der Neuregelung werden alle Ausführungsarten homogen behandelt.
Das bedeutet für Entwickler, dass die Dauer der INIT-Phase künftig im „Billed Duration“ enthalten ist und sich entsprechend auf die Gesamtabrechnung bei On-Demand-Invokationen auswirkt. AWS dokumentiert die Dauer von Aufrufen und Abrechnung bisher im CloudWatch-Log mit Feldern wie Duration, Billed Duration, Memory Size und Init Duration. Nach der Veränderung ändert sich das Abrechnungsverhalten dahingehend, dass die INIT-Dauer mit in die abgerechnete Nutzungszeit aufgenommen wird. Für CloudWatch-Nutzer ergeben sich dadurch neue Möglichkeiten, die INITIALISIERUNGSdauer gezielter zu analysieren und mögliche Einsparpotenziale aufzudecken. Die Anpassung der Abrechnung betrifft nur die On-Demand-Verwendung.
Bei Lambda@Edge wird die INIT-Phase weiterhin gemäß der spezifischen Lambda@Edge-Tarife berechnet. Die Preise für die Dauerberechnung variieren je nach Region und können übersichtlich auf der AWS Lambda Preisübersicht abgerufen werden. Eine genaue Überwachung der INIT-Zeiten lässt sich aktuell schon mit Metriken wie "init_duration" in CloudWatch realisieren. Entwickler haben somit bereits heute das Werkzeug in der Hand, um Ihre Funktionen auf INIT-Leistung und Kostenbasis zu optimieren und sich auf die Umstellung vorzubereiten. Die Häufigkeit von Kaltstarts ist entscheidend für die Auswirkung auf Kosten und Performance.
Kaltstarts entstehen typischerweise, wenn eine Funktion zum ersten Mal ausgeführt wird oder wenn die erforderliche Anzahl an parallelen Ausführungsumgebungen aufgrund einer erhöhten Last skalieren muss. In diesen Fällen wird die INIT-Phase durchlaufen. Bei wiederholten Aufrufen innerhalb eines aktiven Umgebungsfensters – sogenannten Warm Starts – entfällt die erneute Initialisierung, da die Ausführungsumgebung noch bereitsteht. Studien und Nutzungsdaten zeigen, dass Kaltstarts meist unter einem Prozent aller Invokationen ausmachen, wodurch sich die Kostenwirkung für die meisten Anwender auch nach Einführung der neuen Abrechnung in Grenzen hält. Entwickler sind eingeladen, ihre Funktionen so zu gestalten, dass wichtige Initialisierungsschritte sinnvoll in die INIT-Phase gelegt werden.
Das hat den Vorteil, repetitive Arbeit im Handler-Teil zu vermeiden und somit nachfolgende Anfragen schneller abzuarbeiten. Typische Vorbereitungen während INIT umfassen den Download von zusätzlichen Bibliotheken, die Herstellung von Clients zu AWS-Diensten wie Amazon S3 oder DynamoDB sowie das Wiederverwenden von Datenbankverbindungen. Auch das Abrufen von Konfigurationsparametern oder Geheimnissen aus AWS Secrets Manager oder Parameter Store bieten sich an. Der Umfang und die Größe des Funktionspakets beeinflussen die Dauer der INIT-Phase erheblich. Größere Pakete bedingen längere Downloadzeiten und starten entsprechend langsamer.
Daher empfiehlt es sich, die Größe von Anwendungscode und Abhängigkeiten möglichst schlank zu halten. Moderne Tools wie "esbuild" beispielsweise helfen dabei, Bibliotheken zu bündeln und zu minimieren, was die Paketgröße reduziert und Kaltstartzeiten senkt. Ein weiterer Weg zur Optimierung ist das Überdenken, welche Bibliotheken und Ressourcen vor Ort initialisiert und welche dynamisch oder on-demand geladen werden. Mit Blick auf Performance und Kosten ist die Frequenz der INIT-Ausführungen bedeutsam. Je seltener Kaltstarts auftreten, desto geringer der Gesamtaufwand im INIT-Bereich.
Dementsprechend stehen Strategien im Vordergrund, die Kaltstarts zu minimieren. AWS bietet dafür zwei attraktive Lösungen an: Provisioned Concurrency und Lambda SnapStart. Provisioned Concurrency ermöglicht die Vorhaltung und dauerhafte Initialisierung von Ausführungsumgebungen, sodass Funktionen ohne INIT-Verzögerung auf Anfragen reagieren können. Diese Option eignet sich besonders für Anwendungen mit konsistent hohem oder stark schwankendem Verkehrsaufkommen. Obwohl Provisioned Concurrency zusätzliche Kosten verursacht, reduziert es die Gesamtlatenz und macht sich bei entsprechender Nutzung wirtschaftlich bezahlt.
Insbesondere Laufzeiten wie Java oder .NET, die längere INIT-Zeiten aufweisen, profitieren stark von dieser Methode. Lambda SnapStart ist eine innovative Technik, die einen SnapShot der initialen Laufzeitumgebung inklusive Initialisierungszustand erstellt und für folgende Kaltstarts verwendet. Dadurch entfällt die wiederholte Ausführung des INIT-Codes und die Startzeit reduziert sich erheblich. Diese Funktion unterstützt derzeit Java, .
NET und Python und erfordert die Entwicklung im Einklang mit bestimmten Serialisierungsregeln, um die Snapshots nutzen zu können. SnapStart bringt Effizienzvorteile und Kostenersparnisse, ohne die Anwendungslogik zu verändern. Entwickler haben somit viele Ansatzpunkte, um die INIT-Phase gezielt zu gestalten und Kosten zu kontrollieren. Die Kombination aus Paketgrößeoptimierung, schlanker Codeausführung und Nutzung von Funktionen wie SnapStart oder Provisioned Concurrency ist ein effektiver Weg zur Steigerung der Leistungsfähigkeit ihrer Serverless-Anwendungen. Abschließend lässt sich sagen, dass die Standardisierung der INIT-Phasen-Abrechnung bei AWS Lambda ein Schritt zu mehr Transparenz und Einheitlichkeit ist.
