Ein Kaltstart (Cold Start) ist die Verzögerung, die entsteht, wenn eine Serverless- oder Scale-to-Zero-Plattform keine warme Instanz zur Verfügung hat und erst eine neue Ausführungsumgebung erstellen muss. Dazu gehören Sandbox-Bereitstellung, Laden des Codes, Start der Runtime und Initialisierungscode. Sichtbar wird er als zusätzliche Latenz der ersten Anfrage.
Was ein Kaltstart ist
Serverless-Plattformen wie AWS Lambda, Google Cloud Run und Azure Functions führen Ihren Code in Ausführungsumgebungen aus, die sie bei Bedarf erzeugen. Ist bei einer Anfrage eine warme Umgebung verfügbar, wird sie wiederverwendet und nur Ihr Handler läuft. Gibt es keine, weil die Funktion untätig war, der Traffic gerade steigt oder eine neue Version ausgerollt wurde, muss die Plattform zuerst eine neue Umgebung aufbauen. Dieser Zusatzaufwand ist der Kaltstart (Cold Start), und die auslösende Anfrage zahlt ihn vollständig in Form von Latenz.
Kaltstarts betreffen meist nur einen kleinen Teil der Anfragen, treten aber genau dort gehäuft auf, wo es wehtut: im Tail der Latenzverteilung, nach Deployments und bei Lastspitzen.
Was bei einem Kaltstart passiert
Bei AWS Lambda durchläuft eine Umgebung die Phasen Init, Invoke und Shutdown. Der Kaltstart umfasst alles vor dem ersten Invoke:
- Umgebung erzeugen. Die Plattform stellt eine Sandbox bereit (bei Lambda eine Firecracker-MicroVM, bei Cloud Run eine Container-Instanz) und lädt das Code-Paket oder Container-Image.
- Runtime starten. Die Sprach-Runtime bootet, etwa JVM, .NET CLR, Node.js oder Python, dazu eventuelle Lambda-Extensions.
- Funktion initialisieren. Ihr Code außerhalb des Handlers läuft: Imports, Dependency Injection, SDK-Clients, Datenbankverbindungen, Konfiguration und Secrets.
Lambda weist diese Phase als Init Duration in der REPORT-Logzeile des ersten Aufrufs aus. Seit dem 1. August 2025 berechnet AWS die Init-Phase auch für On-Demand-Funktionen mit ZIP-Paketen auf Managed Runtimes. Kaltstarts kosten damit nicht nur Latenz, sondern direkt Geld.
Was Kaltstarts verlängert
| Faktor | Wirkung |
|---|---|
| Runtime | JVM und .NET starten meist langsamer als Node.js, Python oder kompilierte Go- und Rust-Binaries. |
| Paket- oder Image-Größe | Mehr Code und Abhängigkeiten bedeuten mehr Download, Entpacken und Laden. |
| Initialisierungscode | Framework-Bootstrapping, eager aufgebaute Connection Pools und reflexionslastige Dependency Injection kosten Zeit. |
| Speichereinstellung | Bei Lambda wird CPU proportional zum Speicher zugeteilt, kleine Funktionen initialisieren also auch mit weniger CPU. |
| Container-Start (Cloud Run) | Der Container muss gestartet sein und auf seinem Port lauschen, bevor er Traffic erhält. |
Kaltstarts messen
Die OpenTelemetry-Semantic Conventions für FaaS definieren das boolesche Span-Attribut faas.coldstart, das beim ersten Aufruf einer neuen Instanz auf true steht. Damit können Sie die Latenz nach kalten und warmen Aufrufen trennen, statt aus Durchschnittswerten zu raten:
- Kaltstartrate: Anteil der Aufrufe mit
faas.coldstart = true, pro Funktion und Version. - Init-Dauer: Verteilung der Initialisierungszeit, idealerweise als Perzentile p50, p95 und p99.
- Auswirkung auf Nutzer: End-to-End-Latenz der Anfragen mit Kaltstart, im Trace aus Sicht des Aufrufers.
Setzen Sie die Kaltstartrate in Beziehung zu Deployments und Parallelität. Ein Anstieg direkt nach jedem Release ist normal. Eine dauerhaft hohe Rate bei konstantem Traffic deutet meist auf Skalierungsverhalten oder Leerlauf-Timeouts hin.
Kaltstarts reduzieren
- Vorgewärmte Kapazität. Lambda Provisioned Concurrency hält eine festgelegte Zahl initialisierter Umgebungen bereit, Cloud Run nutzt Mindestinstanzen, Azure Functions bietet vorgewärmte bzw. „Always Ready“-Instanzen in den Plänen Premium und Flex Consumption. Alle Varianten tauschen Kosten gegen Vorhersagbarkeit.
- Snapshots. Lambda SnapStart, verfügbar für Java, Python und .NET, stellt eine initialisierte Umgebung aus einem Snapshot wieder her, statt Init erneut auszuführen.
- Mehr CPU beim Start. Der Startup CPU Boost von Cloud Run teilt während des Containerstarts zusätzliche CPU zu, bei Lambda wirkt eine höhere Speichereinstellung ähnlich.
- Schlanker Code. Abhängigkeiten reduzieren, kein Classpath-Scan beim Start, Clients lazy initialisieren und über Aufrufe hinweg wiederverwenden.
- Leichte Instrumentierung. Telemetrie-Layer und Agents wählen, die für Serverless ausgelegt sind, und ihren Einfluss auf die Init-Dauer messen.
Kaltstarts jenseits von Serverless
Derselbe Effekt tritt überall auf, wo Kapazität von null hochskaliert oder neue Instanzen unter Last starten. Kubernetes-Workloads, die mit Knative oder KEDA auf null skalieren, zahlen vor der ersten Anfrage für Image-Pull, Containerstart und Readiness-Probes. Auch JVM-Services haben nach dem Start eine Aufwärmphase: Bis der JIT-Compiler die heißen Codepfade optimiert hat und Caches gefüllt sind, sind die ersten Minuten eines neuen Pods langsamer als der eingeschwungene Zustand. Behandeln Sie diese Fälle wie Serverless-Kaltstarts: Markieren Sie neue Instanzen, vergleichen Sie deren Latenz mit etablierten Instanzen und berücksichtigen Sie die Aufwärmzeit bei Rollouts und Autoscaling-Entscheidungen.
Typische Fehler
Wer nur die durchschnittliche Dauer betrachtet, sieht Kaltstarts überhaupt nicht. Geplante „Keep-Warm“-Pings sind fragil: Sie halten eine Umgebung warm, nicht die vielen, die ein Lastschub braucht. Und schwere Arbeit in den Handler zu verlagern, um Init zu verkürzen, verschiebt die Verzögerung nur auf die erste Anfrage jeder Umgebung.
Wie Obseria unterstützt
Das Serverless Monitoring von Obseria verarbeitet OpenTelemetry-Traces aus Funktionen, sodass sich faas.coldstart und Init-Dauern pro Funktion, Version und Region auswerten und mit der Latenz der aufrufenden Services vergleichen lassen. Für AWS erfasst Obseria Metriken von über 300 Services agentenlos, darunter AWS Lambda.
