Cloud 30 Aug. 2026  ·  5 min read

Warum wir einen Kunden von Lambda weg migriert haben: Eine Cold-Start-Fallstudie (Fehlerrate von 2% auf 0,01%)

Payam
X in ↗
Warum wir einen Kunden von Lambda weg migriert haben: Eine Cold-Start-Fallstudie (Fehlerrate von 2% auf 0,01%) 30 Aug. 2026
TL;DR — Die zentrale Lambda-Funktion eines Kunden hatte bei ungleichmäßigem Traffic Cold Starts — und diese Cold Starts schlugen nicht nur langsam, sondern komplett fehl: eine Fehlerrate von 2%, die sich in 5 nachgelagerte Services fortpflanzte. Die Funktion von Lambda auf eine dauerhaft laufende EC2-Instanz umzuziehen, eliminierte den Cold Start vollständig und senkte die Fehlerrate auf 0,01%. Dieser Artikel erklärt, warum dieses spezifische Fehlerbild auftritt, warum es sich nicht mit den üblichen Lambda-Stellschrauben beheben ließ, und was tatsächlich geholfen hat.

Das Symptom: eine Fehlerrate von 2%, die sich nicht wegtunen ließ

Das Monitoring des Kunden zeigte bei einem Lambda-basierten Service eine konstante Fehlerrate von 2%. Kein Ausreißer, kein Incident — eine dauerhafte Hintergrund-Fehlerrate, die schon lange genug bestand, um als „so ist der Service eben“ hingenommen zu werden. Die Fehler traten nicht zufällig auf: Sie häuften sich nach Phasen ungleichmäßiger Aufruffrequenz — Lastspitzen nach ruhigen Phasen — das typische Muster eines Cold-Start-Problems, kein Code-Bug.

Was das teuer statt nur lästig machte: Die Funktion saß im Aufrufpfad von 5 Services. Ein Fehler auf dieser Ebene blieb nicht isoliert — er pflanzte sich als Retries, Timeouts und Teilausfälle in jedem abhängigen Service fort. Der tatsächliche Blast-Radius war deutlich größer, als das Fehlerbudget der einen Funktion vermuten ließ.

Warum Cold Starts komplett fehlschlugen, statt nur langsam zu sein

Lambda-Cold-Starts werden meist als reines Latenz-Problem beschrieben — der erste Aufruf nach Leerlauf dauert länger, weil die Laufzeitumgebung initialisiert wird. Das stimmt, verharmlost aber das Fehlerbild, das in Produktion tatsächlich wehtut: Wenn die zusätzliche Cold-Start-Latenz einen Request über das Timeout des Aufrufers hinaus verzögert, sieht der Aufrufer nicht „langsam“ — er sieht einen fehlgeschlagenen Request. Wiederholt er den Aufruf und trifft erneut eine kalte Instanz, oder ist das Timeout knapp im Verhältnis zur typischen Cold-Start-Dauer, ist dieser Fehler bei bestimmten Traffic-Mustern deterministisch — kein Zufall.

Die üblichen Lambda-Stellschrauben schlossen diese Lücke hier nicht:

  • Provisioned Concurrency hält eine feste Anzahl Instanzen warm, ist aber ein Kosten-Abdeckungs-Kompromiss — unterdimensioniert, kommt es bei Lastspitzen über der bereitgestellten Anzahl weiterhin zu Cold Starts — genau dann, wenn das Problem auftrat.
  • Mehr Arbeitsspeicher (was auch mehr CPU zuteilt) verkürzt die Cold-Start-Dauer etwas, eliminiert aber nicht das Init-Fenster — es verengt es nur.
  • Die Funktion mit geplanten Pings warmhalten garantiert nur, dass eine Instanz warm bleibt; gleichzeitige Lastspitzen starten trotzdem zusätzliche kalte Instanzen.

Keine dieser Maßnahmen ändert die grundlegende Natur des Problems: Lambdas Ausführungsmodell baut Instanzen basierend auf Traffic und Leerlaufzeit ab und neu auf — kein Tuning entfernt dieses Modell, es verschiebt nur, wo die Cold Starts landen.

Die Lösung: die Funktion von Lambda wegziehen

Für eine Funktion im kritischen Pfad von 5 Services mit nachgelagerten Abhängigkeiten war die richtige Lösung nicht, um Cold Starts herumzutunen — sondern die Bedingung zu entfernen, die sie verursacht. Der Umzug der Workload auf eine EC2-Instanz (oder eine kleine autoskalierte Flotte, dimensioniert auf die tatsächliche Grundlast des Service) bedeutet, dass der Prozess durchgehend läuft. Es gibt keinen Leerlauf-Abbau-Zyklus, also gibt es keinen Cold Start, der ein Timeout auslösen könnte.

Das ist keine pauschale „Lambda schlecht, EC2 gut“-Schlussfolgerung — für wirklich spitze, seltene oder event-getriebene Workloads bleibt Lambdas Pay-per-Invocation-Modell mit null Leerlaufkosten die richtige Wahl. Das Signal, das die Entscheidung kippt, ist spezifisch: eine Funktion mit stabiler Grundlast, im synchronen Aufrufpfad mit knappen nachgelagerten Timeouts, bei der die Cold-Start-Latenz groß im Verhältnis zu diesen Timeouts ist. Diese Kombination macht aus Lambdas Elastizität — normalerweise ein Vorteil — die direkte Ursache der Ausfälle.

Das Ergebnis

Nach der Migration: Die Fehlerrate auf dieser Ebene sank von 2% auf 0,01% — eine Reduktion um etwa das 200-fache. Da die Funktion 5 abhängigen Services vorgelagert war, verbesserte die Lösung die Zuverlässigkeit der gesamten Aufrufkette, nicht nur die eine beobachtete Metrik. Die verbleibenden 0,01% entsprechen echten, vorübergehenden Netzwerk- und Infrastrukturfehlern — der Fehlerrate, die man von einem gesunden, dauerhaft laufenden Service erwarten würde — statt eines strukturellen, traffic-musterbedingten Fehlerbilds.

Wie Sie prüfen, ob das auch bei Ihnen der Fall ist

Bevor Sie annehmen, dass Ihre Lambda-Funktion dasselbe Problem hat, prüfen Sie auf dieses spezifische Muster:

  1. Fehler mit Aufruf-Lücken korrelieren. Vergleichen Sie Ihre Fehler-Zeitstempel damit, ob sie sich nach Phasen niedriger oder fehlender Aufrufe häufen — das ist die Cold-Start-Signatur, im Unterschied zu Fehlern, die gleichmäßig verteilt sind oder an bestimmte Input-Payloads gebunden sind.
  2. Cold-Start-Dauer mit Ihrem knappsten Aufrufer-Timeout vergleichen. Wenn irgendein synchroner Aufrufer dieser Funktion ein Timeout nahe oder unter der beobachteten Cold-Start-Latenz hat, haben Sie ein strukturelles Problem, kein gelegentliches.
  3. Tatsächlich nachgelagerte Abhängigkeiten kartieren. Die eigene Fehlerrate einer Funktion kann isoliert betrachtet tolerierbar wirken, obwohl sie der größte einzelne Beitrag zu Fehlern an anderer Stelle im System ist. Zeichnen Sie den Aufrufgraphen nach, bevor Sie das Risiko als akzeptabel einstufen.

Wann Sie das NICHT tun sollten

Ein paar ehrliche Einschränkungen, denn diese Lösung ist nicht universell:

  • Wirklich spitze oder seltene Workloads. Wenn Ihre Funktion nur wenige Male pro Tag läuft, ohne latenzsensiblen Aufrufer, sind Cold Starts irrelevant — zahlen Sie nicht für eine dauerhaft laufende Instanz, um ein Problem zu lösen, das Sie nicht haben.
  • Workloads, die weit über das hinausskalieren, was Sie auf EC2 verwalten wollen. Lambdas automatische horizontale Skalierung ist ein echter Vorteil bei unvorhersehbarem, breit gefächertem Traffic — der Umzug zu EC2 bedeutet, dass Sie Autoscaling, Patching und Kapazitätsplanung selbst übernehmen.
  • Provisioned Concurrency reicht möglicherweise aus. Wenn Ihr Traffic-Muster vorhersehbar statt sprunghaft ist, kann eine korrekt dimensionierte Provisioned Concurrency die Lücke ohne vollständige Migration schließen. Der EC2-Umzug lohnt sich vor allem, wenn das Traffic-Muster selbst das Problem ist.

Weiterführende Artikel

AWS Lambda Cold Start EC2 Serverless Zuverlässigkeit