Serverless war großartig, bis wir hinter die Durchschnitte schauten. Unsere Java + Spring Boot Lambda zeigte einen P50 von 50ms — und einen P99 von 8.000ms. Cold Starts trafen ungefähr einen von hundert Requests: unsichtbar im Mittelwert, brutal für den, der den Kürzeren zog.

Warum unsere langsam war

  • JVM-Start plus Springs Classpath-Scanning dominierten die 8 Sekunden
  • Ein 250MB großes Deployment-Paket, das erst geholt und entpackt werden musste
  • Niedriger, sprunghafter Traffic, sodass warme Execution Environments ständig abliefen

Eines war nicht das Problem: die VPC-Anbindung. Wir hätten beinahe um einen Rat aus der 2019er-Ära herum neu architektiert, wonach VPC-Networking ein bis zwei Sekunden pro Cold Start addiert. Das ist obsolet, seit AWS Lambda im selben Jahr auf geteilte Hyperplane-ENIs umgestellt hat — der VPC-Cold-Start-Overhead ist heute vernachlässigbar. Wenn ein Blogpost Ihnen etwas anderes erzählt, prüfen Sie sein Datum.

Was wirklich funktioniert hat

  • Lambda SnapStart, zuerst. Es zielt genau auf diesen Workload: Es erstellt nach dem Init einen Snapshot der initialisierten JVM und stellt aus dem Snapshot wieder her, statt kalt zu booten. GA für Java seit 2022 (Python und .NET folgten 2024). SnapStart plus snapshot-sichere Initialisierung senkte unsere Cold Starts von ~8 Sekunden auf deutlich unter eine.
  • Das Paket verkleinern. Das Entfernen ungenutzter Abhängigkeiten brachte uns von 250MB auf 40MB und verkürzte die Zeit für Holen und Entpacken.
  • Provisioned Concurrency dort, wo sie wirklich günstig ist. Wir hatten sie als zu teuer für wenig Traffic abgetan. Das war falsch: Eine einzelne provisionierte Einheit auf einer 1GB-Funktion kostet rund $10 im Monat. Wir halten eine Einheit auf unserem einzigen Endpoint mit harter Latenzanforderung und lassen SnapStart den Rest abdecken.

Was wir ausgelassen haben: geplante Keep-Warm-Pings (fragil, und sie halten nur eine Umgebung warm) und ein komplettes Rewrite auf Node.js — SnapStart machte es unnötig, auch wenn für eine Greenfield-API mit wenig Traffic eine leichtere Runtime ein sinnvoller Default bleibt. Wenn Sie neu auf der Plattform sind: Unser Grundlagenartikel Wie AWS Lambda funktioniert erklärt den Lebenszyklus der Execution Environments hinter all dem.

Danach

  • P50: unverändert bei ~50ms
  • P99: 8.000ms → ~400ms

Lektion: Beim P99 leben Ihre Nutzer wirklich — messen Sie Häufigkeit und Dauer von Cold Starts, bevor Sie sich auf Serverless festlegen, und stellen Sie sicher, dass der Rat, dem Sie folgen, aktuell ist. Wir sehen Teams, die um Probleme herum over-engineeren, die AWS vor Jahren behoben hat; ein kurzes Cloud-Architektur-Review ist günstiger als ein Rewrite.

← Zurück zu Lessons Learned

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.

Tags: #Serverless #AWS #Lambda #Performance