Serverless-Architektur: Wann sich AWS Lambda und Co. wirklich lohnen
Serverless klingt nach einem Versprechen, das zu schön ist, um wahr zu sein: keine Server mehr verwalten, automatisch skalieren und nur das bezahlen, was tatsächlich genutzt wird. In vielen Projekten löst diese Architektur genau diese Probleme. In anderen führt sie zu überraschend hohen Rechnungen und neuen Abhängigkeiten. In diesem Artikel erkläre ich Ihnen, wie Serverless technisch funktioniert, welche Anbieter es gibt, wann sich der Ansatz wirklich lohnt und wann ein klassischer Server, ein VPS oder ein Container die bessere Wahl ist.
Was bedeutet Serverless eigentlich?
Der Begriff „Serverless“ ist irreführend, denn natürlich laufen Ihre Anwendungen weiterhin auf Servern. Der entscheidende Unterschied liegt darin, wer sich um diese Server kümmert. Bei einer Serverless-Architektur übernimmt der Cloud-Anbieter die komplette Verwaltung der Infrastruktur. Sie schreiben nur noch den Code und müssen sich nicht mehr um Betriebssystem, Patches, Skalierung oder Kapazitätsplanung kümmern.
Das zentrale Versprechen lautet: Sie zahlen ausschließlich für die tatsächliche Ausführung Ihres Codes. Läuft Ihre Funktion nicht, entstehen keine Kosten. Das unterscheidet Serverless grundlegend vom klassischen Modell, bei dem ein Server rund um die Uhr läuft und Geld kostet, egal ob er gerade Anfragen bearbeitet oder im Leerlauf wartet.
Hinweis: Serverless ist ein Oberbegriff. Am bekanntesten ist die Variante „Function as a Service“ (FaaS), bei der einzelne Funktionen ausgeführt werden. Dazu kommt „Backend as a Service“ (BaaS), bei dem fertige Bausteine wie Authentifizierung, Datenbanken oder Dateispeicher als verwaltete Dienste bereitgestellt werden. Beide Modelle lassen sich kombinieren.
Wie funktioniert Function as a Service?
Bei FaaS zerlegen Sie Ihre Anwendung in kleine, eigenständige Funktionen. Jede Funktion erfüllt genau eine Aufgabe, zum Beispiel ein hochgeladenes Bild verkleinern, eine Bestellung verarbeiten oder eine E-Mail versenden. Diese Funktionen werden nicht dauerhaft ausgeführt, sondern nur dann gestartet, wenn ein bestimmtes Ereignis sie auslöst.
Solche Ereignisse können vielfältig sein: eine HTTP-Anfrage über ein API-Gateway, ein neuer Eintrag in einer Datenbank, das Hochladen einer Datei in einen Speicher-Bucket oder eine Nachricht in einer Warteschlange. Sobald das Ereignis eintritt, startet der Anbieter eine Ausführungsumgebung, lädt Ihren Code, führt ihn aus und fährt die Umgebung anschließend wieder herunter. Dieser gesamte Lebenszyklus läuft automatisch ab.
Die Skalierung ergibt sich dabei von selbst. Treffen gleichzeitig tausend Anfragen ein, startet der Anbieter im Idealfall tausend parallele Instanzen Ihrer Funktion. Sinkt die Last wieder, werden diese Instanzen abgebaut. Sie müssen weder Load Balancer konfigurieren noch im Voraus abschätzen, wie viele Server Sie benötigen. Genau diese automatische und feingranulare Skalierung ist die größte technische Stärke von Serverless.
Die wichtigsten Serverless-Anbieter im Überblick
Alle großen Cloud-Anbieter haben eine eigene FaaS-Plattform im Portfolio. Sie unterscheiden sich vor allem in der zugrunde liegenden Technologie, im Cold-Start-Verhalten und in der Integration in das jeweilige Ökosystem. Die folgende Tabelle gibt einen kompakten Überblick über die vier relevantesten Anbieter (Stand 2026).
| Anbieter | Technologie | Cold Start (typisch) | Besonderheit |
|---|---|---|---|
| AWS Lambda | microVMs (Firecracker) | ca. 100 ms bis 1 s | Reifster Dienst, tiefste Integration in das AWS-Ökosystem, viele Laufzeiten |
| Azure Functions | Container-basiert | ca. 0,5 bis 3 s | Starke Integration in das Microsoft-Umfeld, mehrere Hosting-Pläne |
| Google Cloud Functions | Container-basiert | ca. 0,2 bis 0,8 s | Gute Anbindung an Firebase und Google-Dienste |
| Cloudflare Workers | V8 Isolates am Edge | nahezu 0 ms | Läuft weltweit am Netzwerkrand, ideal für latenzkritische Web-Workloads |
AWS Lambda gilt als der ausgereifteste und am weitesten verbreitete Dienst und ist für viele Teams der Einstieg in Serverless. Azure Functions und Google Cloud Functions sind dann besonders attraktiv, wenn Sie ohnehin bereits im jeweiligen Ökosystem unterwegs sind. Cloudflare Workers nimmt eine Sonderrolle ein, weil der Dienst nicht auf klassischen Containern basiert, sondern auf leichtgewichtigen V8-Isolates, die direkt am Edge laufen. Dadurch entfallen die Cold Starts praktisch vollständig, allerdings mit Einschränkungen bei Laufzeit und verfügbaren Bibliotheken.
Hinweis: Neben FaaS gehört zu einer typischen Serverless-Architektur fast immer auch BaaS. Dazu zählen verwaltete Datenbanken wie DynamoDB oder Firestore, Authentifizierungsdienste wie AWS Cognito oder Firebase Auth sowie Objektspeicher wie Amazon S3. Erst das Zusammenspiel aus Funktionen und verwalteten Backend-Diensten ergibt eine vollständig serverlose Anwendung.
Die Vorteile von Serverless
Serverless hat sich nicht ohne Grund durchgesetzt. Für bestimmte Anwendungsfälle bietet die Architektur handfeste Vorteile, die mit klassischem Hosting nur schwer zu erreichen sind.
Automatische Skalierung ohne Aufwand
Der wohl größte Vorteil ist die mühelose Skalierung. Ihre Anwendung wächst automatisch mit der Last, von null auf tausende parallele Ausführungen und wieder zurück. Bei unvorhersehbaren oder stark schwankenden Lastspitzen, etwa zu einer Marketing-Aktion oder einem saisonalen Ereignis, müssen Sie nichts vorbereiten. Die Plattform reagiert in Sekunden, ohne dass Sie Server vorhalten oder manuell eingreifen.
Bezahlung nach tatsächlicher Nutzung
Das Pay-per-use-Modell ist für viele Projekte ein finanzielles Argument. AWS Lambda berechnet 2026 beispielsweise 0,20 US-Dollar pro einer Million Anfragen plus einen Bruchteil eines Cents pro genutzter Rechenzeit (GB-Sekunde). Hinzu kommt ein dauerhaftes kostenloses Kontingent von einer Million Anfragen und 400.000 GB-Sekunden pro Monat. Für Anwendungen mit geringer oder sporadischer Last bedeutet das oft Kosten im niedrigen einstelligen Eurobereich oder sogar gar keine Kosten.
Weniger Betriebsaufwand
Sie müssen kein Betriebssystem mehr patchen, keine Server überwachen und keine Kapazitäten planen. Der Anbieter kümmert sich um Verfügbarkeit, Sicherheitsupdates und Ausfallsicherheit. Gerade für kleinere Teams ohne dediziertes Operations-Personal ist das ein erheblicher Vorteil, weil sich die Entwickler stärker auf die eigentliche Anwendung konzentrieren können.
Die Nachteile und Grenzen von Serverless
So überzeugend die Vorteile klingen, Serverless ist kein Allheilmittel. Wer die Architektur unbedacht einsetzt, läuft in mehrere typische Fallstricke, die ich in der Praxis immer wieder sehe.
Cold Starts
Wird eine Funktion nach einer Phase der Inaktivität aufgerufen, muss der Anbieter erst eine neue Ausführungsumgebung hochfahren und Ihren Code laden. Diese Verzögerung wird Cold Start genannt und liegt je nach Anbieter, Laufzeit und Paketgröße zwischen rund 100 Millisekunden und mehreren Sekunden. Für Hintergrundverarbeitung ist das unkritisch. Für eine interaktive Anwendung, bei der jede Millisekunde zählt, kann ein Cold Start jedoch spürbar stören. Gegenmaßnahmen wie Provisioned Concurrency halten Instanzen warm, kosten dann aber wieder Geld und verwässern damit den Pay-per-use-Vorteil.
Vendor Lock-in
Serverless-Anwendungen sind eng mit dem Ökosystem des jeweiligen Anbieters verwoben. Sie nutzen dessen Event-Quellen, dessen Datenbanken, dessen Authentifizierung und dessen proprietäre Schnittstellen. Ein Wechsel von AWS zu Azure oder Google ist deshalb nicht trivial, sondern bedeutet in der Regel erheblichen Umbauaufwand. Container hingegen laufen überall, was sie in puncto Portabilität klar überlegen macht. Wer langfristig flexibel bleiben will, sollte den Lock-in-Faktor bewusst einkalkulieren.
Schwierigeres Debugging und Monitoring
Eine verteilte Anwendung aus vielen kleinen Funktionen ist schwerer nachzuvollziehen als ein klassischer Monolith. Sie können nicht einfach lokal einen Debugger anhängen, sondern sind auf die Logging- und Tracing-Werkzeuge des Anbieters angewiesen. Fehler, die nur unter Last oder bei bestimmten Event-Reihenfolgen auftreten, sind oft mühsam zu reproduzieren. Ein durchdachtes Observability-Konzept ist bei Serverless deshalb keine Option, sondern Pflicht.
Technische Limits
FaaS-Plattformen setzen harte Grenzen. AWS Lambda begrenzt die Ausführungszeit einer Funktion beispielsweise auf 15 Minuten. Auch Arbeitsspeicher, Paketgröße und die Anzahl gleichzeitiger Ausführungen sind limitiert. Für lange laufende Prozesse, rechenintensive Batch-Jobs oder Anwendungen, die persistente Verbindungen oder lokalen Speicher benötigen, ist Serverless schlicht ungeeignet. Hier führt kein Weg an Containern oder klassischen Servern vorbei.
Praxis-Tipp: Der teuerste Fehler, den ich bei Teams beobachte, ist der Betrieb von Serverless-Funktionen unter dauerhaft hoher Last in der Annahme, „Serverless sei ja billiger“. Bei konstant hohem Durchsatz ist das Gegenteil der Fall. Hier wird ein klassischer Server oder Container schnell um ein Vielfaches günstiger als Lambda.
Serverless, Server und Container im Vergleich
Um die richtige Entscheidung zu treffen, hilft ein direkter Vergleich der drei gängigen Hosting-Modelle. Jedes hat seinen klar umrissenen Einsatzbereich. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen.
| Kriterium | Serverless (FaaS) | Container | Klassischer Server / VPS |
|---|---|---|---|
| Skalierung | Automatisch, bis auf null | Automatisch, mit Orchestrierung | Manuell oder begrenzt automatisch |
| Kostenmodell | Pro Ausführung | Pro laufender Instanz | Feste Monatsgebühr |
| Betriebsaufwand | Sehr gering | Mittel | Hoch |
| Cold Starts | Ja, abhängig vom Anbieter | Kaum | Nein |
| Portabilität | Gering (Lock-in) | Hoch | Hoch |
| Laufzeit-Limit | Stark begrenzt (z. B. 15 Min.) | Unbegrenzt | Unbegrenzt |
| Ideal für | Sporadische, ereignisgesteuerte Lasten | Microservices, dauerhafte Dienste | Konstante Last, volle Kontrolle |
In der Praxis schließen sich diese Modelle nicht aus. Viele moderne Architekturen kombinieren sie bewusst. Ein dauerhaft laufender API-Dienst läuft im Container, während sporadische Aufgaben wie Bildverarbeitung oder geplante Reports als Serverless-Funktionen umgesetzt werden. Die Kunst liegt darin, für jeden Baustein das passende Modell zu wählen.
Wann sich Serverless lohnt und wann nicht
Die Entscheidung für oder gegen Serverless hängt vor allem vom Lastprofil Ihrer Anwendung ab. Bei stark schwankender oder seltener Nutzung spielt Serverless seine Stärken aus. Bei konstant hoher Auslastung kehren sich die Vorteile ins Gegenteil.
Serverless lohnt sich bei
Von Serverless absehen sollten Sie bei
Ein Kostenbeispiel zur Veranschaulichung
Theorie ist gut, ein konkretes Rechenbeispiel ist besser. Vergleichen wir die Kosten einer kleinen API über zwei Lastszenarien hinweg. Auf der einen Seite eine Serverless-Lösung, auf der anderen ein günstiger VPS mit fester Monatsgebühr. Die Zahlen sind gerundete Richtwerte und sollen die grundsätzliche Dynamik verdeutlichen, nicht den letzten Cent abbilden.
| Anfragen pro Monat | Serverless (ca.) | VPS (fest, ca.) | Günstiger |
|---|---|---|---|
| 2 Millionen | ca. 11 € | ca. 9 € | Vergleichbar |
| 10 Millionen | ca. 55 € | ca. 12 € | VPS |
| 50 Millionen | ca. 270 € | ca. 18 € | VPS deutlich |
Die Tabelle macht den entscheidenden Punkt sichtbar: Bei geringer Last sind beide Modelle ähnlich teuer, und Serverless punktet zusätzlich mit null Verwaltungsaufwand. Steigt die Last jedoch stark an, explodieren die nutzungsbasierten Kosten, während der feste VPS-Preis kaum wächst. Genau dieser Kipppunkt ist die zentrale Frage bei der Architekturentscheidung. Es gibt reale Fallberichte von Teams, deren Lambda-Rechnung im vierstelligen Bereich lag und die nach einem Wechsel auf klassische Server nur noch einen Bruchteil zahlten.
Hinweis: Achten Sie auf versteckte Kostenfaktoren. Neben der reinen Ausführung berechnen Anbieter oft auch das API-Gateway, den Datentransfer, das Logging und seit August 2025 bei AWS auch die Initialisierungsphase eines Cold Starts. Eine realistische Kalkulation sollte immer die Gesamtarchitektur betrachten, nicht nur den Preis pro Funktionsaufruf.
Wie Cloud-Hosting in das Bild passt
Serverless ist nur eine von mehreren Hosting-Optionen, die Ihnen in der Cloud zur Verfügung stehen. Es ist hilfreich, die gesamte Bandbreite zu kennen, um die Einordnung vorzunehmen. Grob lassen sich vier Ebenen unterscheiden, die sich im Grad der Eigenverantwortung unterscheiden.
Am einen Ende steht der klassische VPS oder Root-Server, bei dem Sie volle Kontrolle haben, aber auch alles selbst verwalten. Darüber liegen Container-Plattformen wie Kubernetes oder verwaltete Container-Dienste, die Skalierung und Orchestrierung übernehmen, Ihnen aber weiterhin Konfigurationsfreiheit lassen. Eine Stufe höher folgen Platform-as-a-Service-Angebote, bei denen Sie nur noch Ihre Anwendung deployen. Ganz am anderen Ende steht Serverless, bei dem Sie sich auf reinen Funktionscode beschränken und die Infrastruktur vollständig aus dem Blick verschwindet.
Wichtig ist die Erkenntnis, dass diese Ebenen keine Konkurrenz sind, aus der Sie genau eine wählen müssen. In ausgereiften Architekturen kommen sie nebeneinander zum Einsatz. Die Datenbank läuft als verwalteter Dienst, die Haupt-API in Containern, einzelne Hintergrundaufgaben als Serverless-Funktionen und statische Inhalte über ein CDN. Diese hybride Herangehensweise verbindet die jeweiligen Stärken und ist in der Praxis oft die wirtschaftlichste Lösung.
Praxis-Tipp: Starten Sie bei neuen Projekten nicht mit der Technologie, sondern mit dem Lastprofil. Wenn Sie nicht genau wissen, wie viel Traffic auf Sie zukommt, ist Serverless oft ein guter, risikoarmer Einstieg. Sie zahlen nur für tatsächliche Nutzung und können einzelne Komponenten später gezielt auf Container umstellen, sobald sich ein stabiles Lastmuster abzeichnet.
Fazit
Serverless ist ein hervorragendes Werkzeug, aber kein universeller Ersatz für klassisches Hosting. Die Architektur glänzt bei ereignisgesteuerten Aufgaben, stark schwankender Last und schnellen Prototypen, weil sie automatisch skaliert, den Betriebsaufwand minimiert und im Leerlauf nichts kostet. Bei konstant hoher Last, langen Prozessen, strengen Latenzanforderungen oder dem Wunsch nach maximaler Portabilität ist ein Container oder ein klassischer Server jedoch die bessere und meist günstigere Wahl.
Meine Empfehlung: Lassen Sie sich nicht vom Hype leiten, sondern von Ihrem konkreten Lastprofil und Ihren Anforderungen. Rechnen Sie die Kosten über realistische Wachstumsszenarien hinweg durch und behalten Sie Cold Starts sowie den Vendor Lock-in im Blick. In den meisten Projekten führt nicht die Entscheidung für ein einzelnes Modell zum Ziel, sondern eine durchdachte Kombination aus Serverless, Containern und verwalteten Cloud-Diensten.
Serverless für Ihr Projekt sinnvoll?
Sie sind unsicher, ob Serverless, Container oder ein klassischer Server zu Ihrem Vorhaben passt? Ich berate Sie zur passenden Cloud-Architektur und übernehme die Umsetzung, von der Planung bis zum produktiven Betrieb.