AWS Lambda ist Amazons event-getriebener Compute-Service: Sie laden eine Funktion hoch, AWS führt für jedes eingehende Event eine Kopie davon aus, und Sie zahlen pro Aufruf. Es gibt keine Server zu provisionieren oder zu patchen, und die Skalierung von null auf Tausende gleichzeitiger Ausführungen erfolgt automatisch. Das ist ein echter Mehrwert — aber "serverless" bedeutet nicht "null Betrieb", und Lambda hat scharfe Kanten, die man kennen sollte, bevor man eine Architektur darauf festlegt.

Wie es funktioniert

Lambda-Funktionen werden durch Events ausgelöst: einen HTTP-Request über API Gateway, eine Datei, die in S3 landet, eine Nachricht in SQS, einen EventBridge-Zeitplan, einen DynamoDB-Stream. Jedes gleichzeitige Event erhält seine eigene Ausführungsumgebung, die Skalierung erfolgt also pro Request statt pro Server. Die offiziell unterstützten Runtimes decken Node.js, Python, Java, .NET, Go und Ruby ab, dazu kommen Custom Runtimes und Container-Images bis 10 GB für alles andere.

Eine Nuance, die das Marketing überspringt: AWS patcht das zugrunde liegende Betriebssystem und die Runtime, aber die Runtime-Version gehört Ihnen. Runtimes werden nach dem Zeitplan von AWS abgekündigt — Node.js-Versionen wandern von 18 über 20 auf 22, Python-Versionen altern heraus — und jede Deprecation erzwingt einen Test-und-Upgrade-Zyklus über Ihre gesamte Funktionsflotte. Teams mit Hunderten von Funktionen spüren das als wiederkehrende Betriebssteuer.

Das Preismodell

Lambda rechnet über zwei Zähler ab: Requests (derzeit 0,20 $ pro Million) und Compute-Dauer in GB-Sekunden — Speicherzuweisung multipliziert mit Ausführungszeit, mit 1-ms-Granularität (rund 0,0000167 $ pro GB-Sekunde auf x86, etwas weniger auf Graviton). Der Speicher ist von 128 MB bis 10 GB konfigurierbar, und die CPU skaliert mit, sodass mehr Speicher eine Funktion oft schneller und kaum teurer macht. Das Gratiskontingent umfasst eine Million Requests und 400.000 GB-Sekunden pro Monat. Die Konsequenz: Lambda ist bei niedrigem oder sprunghaftem Traffic extrem günstig und bei dauerhaft hoher Auslastung zunehmend teuer — dort gewinnt in der Regel ein durchlaufender Container auf Fargate oder EC2, oft kombiniert mit Savings Plans. Rechnen Sie mit Ihrem realen Traffic, bevor Sie entscheiden.

Cold Starts und wie man sie abmildert

Wenn ein Request eintrifft und keine warme Ausführungsumgebung existiert, muss Lambda eine erzeugen: den Code herunterladen, die Runtime starten, Ihre Initialisierung ausführen. Dieser Cold Start reicht von einigen Dutzend Millisekunden bei einer kleinen Python- oder Node.js-Funktion bis zu mehreren Sekunden bei einer schwergewichtigen JVM- oder .NET-Anwendung. Bei niedrigem Traffic trifft ein spürbarer Anteil der Requests auf Cold Starts — einen realen p99-Vorfall haben wir in unserem Lambda-Cold-Start-Lesson-Learned dokumentiert.

Gegenmaßnahmen, in der Reihenfolge, in der man sie ausprobieren sollte: Deployment-Pakete klein und die Initialisierung lazy halten; wo praktikabel, leichtere Runtimes bevorzugen; SnapStart aktivieren (verfügbar für Java, .NET und Python), das Funktionen aus einem vorinitialisierten Snapshot fortsetzt und Cold Starts typischerweise um eine Größenordnung verkürzt — kostenlos für Java, für die anderen pro Cache-und-Restore berechnet; und für harte Latenz-SLOs Provisioned Concurrency kaufen, die Umgebungen warm hält, aber auch im Leerlauf abrechnet.

Wann man Lambda NICHT einsetzen sollte

  • Lang laufende Arbeit. Das harte 15-Minuten-Timeout schließt große Batch-Jobs aus — orchestrieren Sie mit Step Functions oder führen Sie mit AWS Batch und Fargate aus.
  • Dauerhafter, vorhersehbarer High Traffic. Die GB-Sekunden-Abrechnung verliert gegen durchlaufende Container, sobald die Auslastung konstant hoch ist.
  • Strikte Low-Latency-p99s, ohne für Provisioned Concurrency zu bezahlen.
  • Langlebige Verbindungen. WebSockets und Streaming-Sessions kämpfen gegen das Ausführungsmodell.
  • Portabilitätsanforderungen. Event-Formate, IAM-Verdrahtung und Service-Integrationen koppeln Sie an AWS; das ist oft ein fairer Tausch, aber treffen Sie ihn bewusst.

Für Event-Glue, APIs mit sprunghaftem Traffic und Hintergrundverarbeitung bleibt Lambda der pragmatische Default auf AWS — und das saubere Deployment ist ein gelöstes Problem; siehe unseren Leitfaden zum Lambda-Deployment aus GitHub Actions mit OIDC. Wenn Sie für einen neuen Workload Serverless gegen Container abwägen, macht unsere Cloud-Computing-Practice genau diese Art von Architektur- und Kostenbewertung.

Betreiben Sie so etwas in Produktion? Unser AWS-Managed-Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab 3.000 €/Monat.

Tags: #AWS #Serverless #Cloud #FaaS