Warum Serverless die einzig sinnvolle Architektur-Entscheidung ist

Serverless heißt nicht "kein Server" - ja, klar. Das haben wir alle verstanden. Weiter.

Aber was heißt Serverless dann? Viele denken dabei an Lambda - Funktionen deployen, fertig. Aber eine Lambda vor einer provisionierten RDS-Datenbank ist keine Serverless-Architektur. Das ist eine Lambda vor klassischer Infrastruktur.

Die Kern-DNA eines echten Serverless-Service: keine Kapazitätsplanung. Kein Sizing, kein Overprovisioning, keine Capacity Units, die irgendwo versteckt sind. Einfach nutzen - der Service skaliert selbst. Auf Null, nach oben, egal.

Und Serverless wird umso interessanter, je größere Teile des Stacks so funktionieren. Compute, Storage, Integration, API - alles eigenständig elastisch.

In diesem Artikel geht es darum, welche AWS-Services dazugehören, wo die echten Vorteile liegen - und wo es anfängt, wehzutun.

Das Serverless-Paradox

Der erste Service, den AWS jemals veröffentlicht hat, war SQS - 2004. Keine Kapazitätsplanung, Pay-per-Use, skaliert einfach. Dann kamen S3, SNS, SES, DynamoDB. Alles Services, die man einfach nutzt. AWS hat jahrelang serverless Services gebaut, ohne das Wort ein einziges Mal zu verwenden.

2014 kam Lambda, und plötzlich hatte das Kind einen Namen. "Serverless" wurde zum Buzzword. Und dann passierte etwas Seltsames: Bei AWS ist, wo Serverless draufsteht, eigentlich nie Serverless drin. Aurora Serverless, OpenSearch Serverless, MSK Serverless, ElastiCache Serverless - überall versteckte Capacity Units oder Mindestkosten.

Die Bausteine einer Serverless-Architektur

Aber welche Services finden sich nun in jeder guten Serverless-Architektur auf AWS?

Compute ist natürlich meistens Lambda. Kurzlebige Funktionen, event-getrieben, skalieren schnell und ohne Stress. Der natürliche Einstieg in das Thema Serverless.

Storage und Datenbanken bilden das Fundament: S3 für Objekte, DynamoDB (On-Demand) für strukturierte Daten mit Single-Digit-Millisecond-Latency, EFS, wenn ein richtiges Dateisystem gebraucht wird.

Integration ist das Nervensystem. EventBridge für Event-Routing, Scheduling und Integration, Step Functions für Orchestrierung, SQS und SNS für Entkopplung und Messaging. Hier entsteht die eigentliche Architektur - nicht im Compute, sondern in der Art, wie Services miteinander kommunizieren.

API und Streaming: API Gateway und AppSync für synchrone Schnittstellen nach außen, Firehose für das Laden, Transformieren und Weiterleiten von Streaming-Daten in Richtung S3, Redshift, OpenSearch oder externe Ziele.

Analytics: Athena für SQL-Queries direkt auf S3 - keine Infrastruktur, Pay-per-Query.

Und dann gibt es da noch Fargate. Im Kern ist es ein Auto-Scaling Docker Runner: Du gibst AWS ein Container-Image mit CPU- und Memory-Vorgaben, AWS kümmert sich um den Rest. Quasi serverlose Server, kein OS, kein Patching, aber du triffst trotzdem Sizing-Entscheidungen. Fargate hat seine Berechtigung in Serverless-Architekturen: für lang laufende Prozesse, Container-basierte Workloads oder wenn Lambda schlicht nicht passt. Manchmal braucht man halt einfach einen Server 😉

Die echten Vorteile

Pay-per-Use klingt simpel, verändert aber grundlegend, wie man über Kosten nachdenkt. Kein Idle-Server, der nachts durchläuft. Kein Cluster, den keiner runterfahren wollte. Wenn nichts passiert, kostet's nichts - Scale-to-Zero. Von Speicher mal abgesehen. Nachts ist halt oft nix los - und das sind gut zehn Stunden am Tag, in denen klassische Infrastruktur Geld verbrennt. Serverless dagegen bedeutet 100% Utilization.

Aber Skalierung ist mehr als nur Lambda. Es bringt nichts, wenn die Funktionen auf tausende Requests hochskalieren, aber die Datenbank dahinter umfällt. Das ist der eigentliche Vorteil einer durchdachten Serverless-Architektur: Jeder Baustein skaliert für sich - und das schwächste Glied in der Kette bremst nicht den ganzen Stack aus. Man verdrahtet die richtigen Services miteinander und es läuft.

Der vielleicht am meisten unterschätzte Vorteil liegt aber woanders: Der beste Code ist der, den man nicht schreiben muss. Serverless auf AWS bedeutet, dass ein riesiger Teil der Integrationslogik in die Infrastruktur wandert. API Gateway kann direkt in viele Services integrieren - ohne Lambda dazwischen. EventBridge Pipes reichen Informationen weiter, ohne dass du Glue-Code schreibst. Lambda-Trigger auf S3, DynamoDB Streams, SQS - die Verkabelung zwischen Services ist nativ, nicht selbstgebaut.

Das heißt am Ende: Ein Team kann sich schneller bewegen, weil es auf einen Baukasten zurückgreift, der einfach gut zusammen spielt. Nicht mehr alles selbst bauen - sondern verdrahten. Vorausgesetzt, man weiß, welche Drähte wohin gehören 🤓

Die Trade-offs - ehrlich betrachtet

Jede Architekturentscheidung ist ein Trade-off. Serverless hat klare Stärken - aber eben nicht nur. Wer die Trade-offs kennt, setzt es dort ein, wo die Vorteile voll zum Tragen kommen und die Nachteile keine Rolle spielen.

Cold Starts

Cold Starts sind das Erste, was in jeder Serverless-Diskussion aufkommt. Ja, sie existieren. Für die meisten Workloads - asynchrone Verarbeitung, Event-Processing, APIs mit moderaten Latenzanforderungen - sind sie kein Problem. Wo es eng wird: synchrone APIs, bei denen jede Millisekunde zählt. Provisioned Concurrency löst das, kostet aber und widerspricht dem Scale-to-Zero-Gedanken. Für solche Fälle kann Fargate eine fast serverlose Alternative sein - oder Lambda Managed Instances, ein seit re:Invent 2025 verfügbares Deployment-Modell, bei dem Lambda-Funktionen auf dedizierten EC2-Instanzen laufen und Cold Starts kein Thema mehr sind. Es heißt zwar noch Lambda, ist aber kein Serverless mehr.

Vendor Lock-in

Vendor Lock-in ist ein Thema, keine Frage. Deine EventBridge-Rules und Step-Function-Definitionen laufen nirgendwo anders. Aber immerhin: die Business-Logik in deinen Lambda-Funktionen ist normaler Code, der überall läuft. Was dich bindet, ist die Integrations-Schicht - nicht die Logik. Und mal ehrlich: wer jahrelang auf einer Plattform aufgebaut hat, zieht eh nicht einfach so um.

Debugging und Observability

Debugging und Observability sind in verteilten Serverless-Architekturen schwieriger als in klassischen Setups. Ein Request wird durch mehrere Services gereicht, Funktionen reagieren auf Events, und nach dem Schreiben in die Datenbank wird über einen Stream nochmal eine Weiterverarbeitung getriggert. Wenn etwas schiefläuft, gibt es nicht den einen Log, in dem man alles sieht. Mit X-Ray, CloudWatch Logs und Structured Logging hat man Werkzeuge an der Hand, um trotzdem zu wissen, was Sache ist.

Kosten bei konstanter Last

Kosten bei konstanter Last sind der Punkt, an dem das Pay-per-Use-Modell kippen kann. Wenn deine Workload 24/7 auf gleicher, vorhersehbarer Last läuft, summiert sich jeder einzelne Request. Ab einem gewissen Punkt ist Fargate mit Compute Savings Plans schlicht günstiger. Oder man bleibt bei Lambda: Mit Managed Instances lassen sich Lambda-Funktionen auf dedizierten EC2-Instanzen betreiben - mit Savings Plans, Reserved Instances und ohne den operativen Overhead. Der perfekte Übergang von der Wachstums- in die Steady-State-Phase. Aber: kein Produkt startet mit einer festen User Base auf Dauerlast. Sowas wächst über Jahre - und dann gezielt einzelne Komponenten auf dedizierte Infrastruktur umzustellen, ist ein völlig normaler Schritt.

Architektur-Komplexität

Architektur-Komplexität wächst mit jedem Service, den du hinzufügst. Hundert Lambda-Funktionen, die über EventBridge, SQS und Step Functions verbunden sind, können schnell unübersichtlich werden. "Death by a thousand Lambdas" ist real, wenn man jede kleine Aufgabe in eine eigene Funktion packt. Gutes Domain-Design - bis hin zu einer durchdachten Multi-Account-Strategie - hilft den Überblick zu behalten.

Wann lohnt sich Serverless - und wann nicht?

Serverless spielt seine Stärken in klaren Szenarien aus. Asynchrone Verarbeitung: Ein Bild wird hochgeladen, eine Benachrichtigung geht raus. APIs mit variabler Last, bei denen mittags Peak ist und nachts Stille. MVPs und Prototypen, bei denen man schnell produktiv sein will. Und ganz generell: wenn man sich noch in der Aufbau- und Wachstumsphase befindet, agil bleiben will und Zugang zu Kapazität braucht, ohne Kosten upfront. Und wenn es dann endlich richtig rund geht, ist der Slashdot-Effekt nicht mehr der Hug of Death, sondern nur noch ein Hug 🤗

Weniger ideal wird es bei latenz-kritischen Anwendungen, bei denen Cold Starts ein echtes Problem sind, bei konstanter Volllast, wo Lambda Managed Instances inzwischen eine Brücke schlagen, oder bei lang laufenden Prozessen, die über das Lambda-Timeout von 15 Minuten hinausgehen - hier ist Fargate die bessere Wahl.

In der Praxis ist es selten ein Entweder-oder. Die meisten Architekturen sind hybrid - und das ist auch gut so. Serverless fügt sich nahtlos in bestehende Infrastruktur ein und kann sie Stück für Stück erweitern, modernisieren oder ersetzen.

Fazit

Serverless auf AWS ist kein Trend mehr - es ist ein ausgereifter Architektur-Ansatz mit einem breiten Ökosystem, das weit über Lambda hinausgeht und seine Wurzeln in den allerältesten AWS-Services hat.

Die Entscheidung für oder gegen Serverless ist keine Glaubensfrage. Sie hängt am Traffic-Muster, am Team, an den Anforderungen - und sie muss nicht binär sein. Pragmatismus schlägt Dogma. Aber wer heute ein neues Projekt auf AWS startet und nicht zuerst an Serverless denkt, verschenkt einen massiven Vorsprung. Und wer sich nicht sicher ist, ob er den roten oder den grünen Draht durchschneiden soll - meldet euch 😉