Eine Webanwendung soll zuverlässig skalieren, ohne dass jemand virtuelle Maschinen patchen, Kapazitäten vorplanen oder nachts auf Lastspitzen reagieren muss. Genau hier setzt AWS Lambda an: Ich zeige, wie der serverlose Dienst arbeitet, wofür er sich im Hosting und DevOps eignet, welche Kosten und Grenzen gelten und wie sich typische Probleme wie Kaltstarts vermeiden lassen.
Die wichtigsten Fakten zu AWS Lambda auf einen Blick
- Serverloses Hosting führt Code ereignisgesteuert aus, ohne dass eigene Server verwaltet werden.
- Automatische Skalierung passt die Zahl der Ausführungsumgebungen an die Nachfrage an.
- 15 Minuten beträgt die maximale Laufzeit einer normalen Lambda-Ausführung.
- Abrechnung nach Nutzung basiert auf Aufrufen und Ausführungsdauer in GB-Sekunden.
- CloudWatch, IAM und IaC bilden die Grundlage für Betrieb, Sicherheit und reproduzierbare Deployments.
Was AWS Lambda eigentlich leistet
AWS Lambda ist ein serverloser Compute-Dienst von Amazon Web Services. Der Entwickler liefert den Code, die Abhängigkeiten und einen Einstiegspunkt, den sogenannten Handler. AWS übernimmt anschließend die Bereitstellung der Laufzeitumgebung, das Skalieren, die Infrastrukturwartung und viele Sicherheitsupdates.
Eine Funktion läuft nicht dauerhaft wie ein klassischer Webserver. Sie wird durch ein Ereignis gestartet, verarbeitet die übergebenen Daten und endet danach wieder. Ein solches Ereignis kann eine HTTP-Anfrage, ein neues Objekt in Amazon S3, eine Nachricht in Amazon SQS oder ein Eintrag in Amazon DynamoDB sein.
Ich sehe Lambda deshalb weniger als vollständigen Serverersatz und eher als Baustein für ereignisgetriebene Anwendungen. Das passt besonders gut zu APIs, Automatisierungen, Datenverarbeitung und Hintergrundaufgaben, bei denen die Last schwankt oder einzelne Verarbeitungsschritte klar voneinander getrennt werden können.
So läuft eine Funktion ab
- Ein AWS-Dienst oder eine Anwendung erzeugt ein Ereignis.
- Lambda erstellt bei Bedarf eine isolierte Ausführungsumgebung.
- Die Laufzeit übergibt Ereignisdaten und Kontext an den Handler.
- Der Code verarbeitet die Anfrage und liefert ein Ergebnis oder schreibt es in einen anderen Dienst.
Die Funktion ist grundsätzlich zustandslos. Daten, die über mehrere Aufrufe hinweg erhalten bleiben müssen, gehören deshalb in Dienste wie DynamoDB, S3 oder eine Datenbank. Temporäre Dateien können im Verzeichnis /tmp liegen, sollten aber nicht als dauerhafte Ablage eingeplant werden.
Für welche Hosting-Aufgaben Lambda sinnvoll ist
Die größte Stärke zeigt Lambda bei Anwendungen, deren Auslastung nicht konstant ist. Eine kleine Firmenwebsite mit sporadischen Formularübertragungen, eine API mit unvorhersehbaren Zugriffsspitzen oder ein Bildverarbeitungsprozess nach einem Upload zahlen nicht für dauerhaft laufende Leerlaufkapazität.
Typische Einsatzfälle im Hosting und DevOps sind:
- Backend-APIs mit Amazon API Gateway oder einer Function URL
- Automatisierte Deployments, etwa zur Prüfung von Cloud-Ressourcen oder zur Bereinigung alter Artefakte
- Dateiverarbeitung nach dem Upload in einen S3-Bucket
- Asynchrone Jobs über SQS, zum Beispiel für E-Mails, Rechnungen oder Datenimporte
- Monitoring-Aktionen, die auf CloudWatch-Alarme reagieren
- ETL-Schritte, bei denen Daten aus Streams oder Warteschlangen verarbeitet werden
Ein konkretes Beispiel macht die Architektur greifbar. Ein Nutzer lädt ein Foto hoch, S3 löst eine Funktion aus, Lambda erzeugt mehrere Bildgrößen und speichert sie wieder in S3. Der Webserver muss nicht warten, der Prozess lässt sich unabhängig skalieren und Fehler können über eine Warteschlange erneut verarbeitet werden.
Für eine klassische, dauerhaft laufende Anwendung mit vielen offenen Verbindungen oder langen Rechenprozessen ist Lambda dagegen nicht automatisch die beste Wahl. Dort können Container mit Amazon ECS und Fargate oder virtuelle Maschinen mit Amazon EC2 besser kalkulierbar sein.
Wie man Lambda sauber in eine DevOps-Pipeline integriert
Für einen schnellen Test reicht die AWS-Konsole. Im produktiven Betrieb würde ich Funktionen jedoch nicht manuell in der Konsole pflegen. Besser ist ein deklarativer Ansatz mit AWS SAM, AWS CDK, Terraform oder CloudFormation. Infrastruktur, Berechtigungen und Konfiguration liegen dann versioniert im Repository.
Ein praxistauglicher Ablauf
- Die Anwendung wird als kleine, testbare Funktion strukturiert.
- Unit-Tests prüfen die Geschäftslogik unabhängig von AWS-Ereignissen.
- Ein Build-Prozess erstellt ein ZIP-Paket oder ein Container-Image.
- Eine Infrastructure-as-Code-Vorlage beschreibt Funktion, Trigger, IAM-Rolle und Alarme.
- Die Pipeline deployt zuerst in eine Testumgebung.
- Integrationstests prüfen echte Verbindungen zu API Gateway, SQS, S3 oder Datenbanken.
- Ein Alias oder eine Version ermöglicht kontrollierte Releases und Rollbacks.
Der Handler sollte möglichst dünn bleiben. Er validiert das Ereignis, ruft die eigentliche Geschäftslogik auf und formatiert die Antwort. Diese Trennung macht Tests schneller und verhindert, dass jede Prüfung eine vollständig konfigurierte AWS-Umgebung benötigt.
Für produktive Deployments nutze ich außerdem gestufte Releases. Eine neue Version kann zunächst nur einen kleinen Teil des Datenverkehrs erhalten. Erst wenn Fehlerrate, Latenz und Geschäftsmetriken stabil bleiben, wird der Anteil erhöht.
Berechtigungen gehören zum Deployment
Jede Funktion erhält eine IAM-Rolle. Diese Rolle sollte nur die Aktionen erlauben, die der Code tatsächlich benötigt. Eine Funktion, die eine Datei aus S3 liest, braucht beispielsweise keine Berechtigung, sämtliche Buckets zu löschen.
Viele Lambda-Probleme sehen zunächst wie Programmierfehler aus, sind aber falsch gesetzte IAM-Rechte oder fehlerhafte Netzwerkregeln. Deshalb sollten Berechtigungen, Subnetze, Security Groups und Umgebungsvariablen gemeinsam mit dem Code getestet werden.
Was AWS Lambda kostet und wo die Grenzen liegen
Lambda Functions werden im Wesentlichen nach Anzahl der Aufrufe und Ausführungsdauer berechnet. Die Laufzeit hängt von der gewählten Speichermenge ab, weil AWS damit auch den verfügbaren CPU-Anteil erhöht. In der Standardpreisstruktur kostet eine Million Aufrufe 0,20 US-Dollar, zusätzlich fallen Gebühren für die verbrauchten GB-Sekunden an.
Das monatliche kostenlose Kontingent umfasst derzeit 1 Million Aufrufe und 400.000 GB-Sekunden. Hinzu kommen mögliche Kosten für API Gateway, S3, DynamoDB, CloudWatch, Datenübertragung oder NAT Gateway. Eine Funktion selbst kann also günstig sein, während die angeschlossene Architektur die Rechnung deutlich stärker beeinflusst.
| Parameter | Typischer Richtwert | Praktische Bedeutung |
|---|---|---|
| Speicher | 128 MB bis 10.240 MB | Mehr Speicher bedeutet meist auch mehr CPU-Leistung. |
| Maximale Laufzeit | 900 Sekunden | Normale Funktionen sind für kurze Aufgaben gedacht. |
| Umgebungsvariablen | 4 KB insgesamt | Große Konfigurationen gehören eher in Secrets Manager oder Parameter Store. |
| Standard-Konkurrenzlimit | 1.000 Ausführungen pro Region | Das Limit kann je nach Konto und Region angepasst werden. |
Die günstigste Speichereinstellung ist nicht automatisch die wirtschaftlichste. Eine Funktion mit 128 MB, die 2 Sekunden läuft, kann teurer oder langsamer sein als dieselbe Funktion mit 1.024 MB, die nach 300 Millisekunden fertig ist. Ich würde deshalb mehrere Konfigurationen messen und nicht nur den Preis pro Ausführung vergleichen.
Problematisch wird Lambda bei konstant hoher Auslastung, sehr langen Jobs oder großen Datenmengen. Die harte Laufzeitgrenze von 15 Minuten lässt sich nicht einfach wegkonfigurieren. Für längere Workflows eignen sich Step Functions, Batch, Fargate oder andere spezialisierte Dienste besser.
Kaltstarts, Leistung und Zuverlässigkeit in der Praxis
Ein Kaltstart entsteht, wenn Lambda eine neue Ausführungsumgebung vorbereiten muss. Dabei werden Laufzeit, Code und Abhängigkeiten geladen. Bei einem warmen Start kann eine bereits vorhandene Umgebung wiederverwendet werden, weshalb die Antwort meist schneller erfolgt.
Kaltstarts sind nicht bei jedem Aufruf zu erwarten, können bei selten genutzten Funktionen oder starkem Hochskalieren aber relevant werden. Die Dauer reicht je nach Laufzeit und Paketgröße von sehr kurz bis deutlich spürbar. Besonders schwere Frameworks, große Container-Images und umfangreiche Initialisierung erhöhen die Wartezeit.
Lesen Sie auch: Docker oder VM? Die passende Basis für Hosting und DevOps
Was gegen unnötige Latenz hilft
- Abhängigkeiten reduzieren und nur wirklich benötigte Bibliotheken ausliefern
- SDK-Clients und unveränderliche Konfiguration außerhalb des Handlers initialisieren
- Schwere Datenbanken oder Netzwerkverbindungen nicht bei jedem Aufruf neu aufbauen
- Speichergröße mit realen Lasttests optimieren
- Für planbare niedrige Latenz Provisioned Concurrency prüfen
- Bei unterstützten Laufzeiten SnapStart als Alternative untersuchen
Provisioned Concurrency hält eine festgelegte Anzahl vorbereiteter Umgebungen bereit. Das verbessert die Reaktionszeit, verursacht aber zusätzliche Kosten. SnapStart kann bei unterstützten Laufzeiten die Initialisierung beschleunigen, bringt jedoch Einschränkungen bei Kompatibilität und Ressourcen mit sich.
Zuverlässigkeit entsteht nicht allein durch automatische Skalierung. Asynchrone Ereignisse sollten mit Wiederholungen und einer Dead-Letter-Queue abgesichert werden. Bei synchronen APIs braucht es klare Timeouts, sinnvolle Retries und Schutz vor einem sogenannten Retry-Sturm, bei dem ein Fehler die Last weiter erhöht.
Monitoring und Sicherheit gehören zum Grundbetrieb
Eine Lambda-Anwendung ist nur dann professionell betrieben, wenn Fehler und Engpässe sichtbar sind. Amazon CloudWatch liefert unter anderem Metriken für Fehler, Dauer, Aufrufe, Throttling und parallele Ausführungen. Für kritische Funktionen würde ich zusätzlich Alarme auf Fehlerrate, p95-Latenz und verbrauchtes Konkurrenzlimit einrichten.
Logs sollten eine Korrelations-ID enthalten, damit eine Anfrage über API Gateway, Lambda, SQS und Datenbank hinweg verfolgt werden kann. Für komplexe Abläufe helfen strukturierte JSON-Logs und AWS X-Ray oder eine vergleichbare Tracing-Lösung.
Bei personenbezogenen Daten gelten auch in einer serverlosen Architektur die Anforderungen der DSGVO. Eine Region wie Frankfurt kann für deutsche Projekte sinnvoll sein, sie ersetzt aber keine Datenschutzprüfung. Verschlüsselung, Zugriffskontrolle, Aufbewahrungsfristen und die Auswahl angeschlossener Dienste bleiben Aufgaben des Betreibers.
Ein häufiger Fehler ist die zu großzügige IAM-Rolle. Ein anderer besteht darin, Geheimnisse direkt in den Quellcode oder in eine ungeschützte Umgebungsvariable zu schreiben. Für Passwörter und API-Schlüssel sind AWS Secrets Manager oder Systems Manager Parameter Store die geeignetere Lösung.
Wann Lambda die richtige Entscheidung ist
Ich würde Lambda bevorzugen, wenn eine Anwendung ereignisorientiert arbeitet, schnell auf Laständerungen reagieren muss und einzelne Aufgaben klar abgrenzbar sind. Auch kleine Teams profitieren davon, dass sie sich nicht um Betriebssystem-Updates, Serverkapazitäten und Load Balancer kümmern müssen.
| Anforderung | Passende Wahl | Warum |
|---|---|---|
| Sporadische API-Aufrufe | Lambda mit API Gateway | Automatische Skalierung und nutzungsabhängige Abrechnung |
| Dateien nach Upload verarbeiten | Lambda mit S3 | Einfache ereignisgetriebene Verarbeitung |
| Lange oder kontinuierliche Prozesse | Fargate, EC2 oder Batch | Keine enge Lambda-Laufzeitgrenze |
| Konstant hohe Grundlast | Container oder Managed Instances | Planbarere Kosten bei dauerhaftem Betrieb |
| Workflow mit mehreren Schritten | Lambda mit Step Functions | Status, Wiederholungen und Verzweigungen werden sauber orchestriert |
Serverless bedeutet außerdem nicht automatisch billig, wartungsfrei oder simpel. Die Server verschwinden aus dem eigenen Zuständigkeitsbereich, aber Architektur, Berechtigungen, Limits, Observability und Kostenkontrolle bleiben. Genau dort entscheidet sich, ob aus einer schnellen Lambda-Lösung ein belastbares Produktionssystem wird.
Der sinnvollste Start für ein neues Projekt
Für den Einstieg empfehle ich eine kleine, vollständige Anwendung statt einer isolierten Demo. Ein S3-Upload, eine Lambda-Funktion, eine SQS-Warteschlange, ein CloudWatch-Alarm und ein automatisiertes Deployment zeigen bereits die wichtigsten Prinzipien.
Beginne mit einer Funktion, die eine klar begrenzte Aufgabe erledigt. Miss Laufzeit und Speicherverbrauch unter realistischen Bedingungen, simuliere Fehler und prüfe die Berechtigungen. Erst danach lohnt es sich, über Provisioned Concurrency, VPC-Anbindung oder komplexe Optimierungen nachzudenken.
Mein wichtigster Rat lautet daher, Lambda nicht nur als günstige Hosting-Option zu betrachten. Richtig eingesetzt ist es ein präzises Werkzeug für skalierbare, ereignisgetriebene Systeme, dessen Nutzen besonders dann sichtbar wird, wenn Code, Infrastruktur und Betrieb von Anfang an gemeinsam gedacht werden.
