Serverless vs Container — Architektur-Entscheidung für den Mittelstand 2026

Die Entscheidung zwischen Serverless und Container ist eine der folgenreichsten Architektur-Festlegungen, die Sie in einem Cloud-Projekt treffen — sie prägt Kosten, Betriebsmodell, Team-Skills und Migrations-Optionen für viele Jahre. Gleichzeitig wird die Debatte fast immer ideologisch geführt: Serverless-Enthusiasten verkünden das Ende der Server, Container-Verfechter halten Serverless für ein Hype-Thema mit Vendor-Lock-in. Beide Lager liegen falsch. Die korrekte Antwort lautet in fast allen mittelständischen Architekturen: beides, an den jeweils passenden Stellen. Dieser Artikel räumt die Mythen aus dem Weg, zeigt anhand realer Workload-Muster wann welche Variante gewinnt, vergleicht die wichtigsten Anbieter-Plattformen mit ihren echten Limits, beleuchtet Cold-Start-Realität und Vendor-Lock-in nüchtern und führt zu einem konkreten Hybrid-Modell mit Kostenbeispielen. Für den Gesamtüberblick siehe unseren Cloud-und-DevOps-Guide für den Mittelstand.

Worum es eigentlich geht

Bevor wir vergleichen, lohnt eine saubere Begriffsklärung — der Markt vermengt drei Konzepte, die technisch und kommerziell sehr unterschiedlich sind. FaaS (Function-as-a-Service) wie AWS Lambda, Azure Functions oder GCP Cloud Functions führt einzelne Funktionen aus, die durch Ereignisse ausgelöst werden — eine eingehende HTTP-Anfrage, ein S3-Upload, ein Timer, eine Queue-Message. Sie zahlen ausschließlich für die tatsächliche Ausführungszeit in Millisekunden, oft kombiniert mit Speicher-Sekunden. Zwischen den Aufrufen läuft buchstäblich nichts; die Plattform startet bei Bedarf eine neue Instanz.

Container sind das andere Extrem — Sie betreiben langlebige Prozesse in einem Linux-Container, der dauerhaft Speicher belegt und CPU-Anteile reserviert hat. Egal ob ein Aufruf pro Sekunde oder kein Aufruf — der Container läuft, und Sie zahlen für die reservierten Ressourcen. Container-Plattformen reichen vom selbstverwalteten Kubernetes-Cluster über managed Kubernetes (EKS, AKS, GKE) bis zu Fully-Managed-Diensten wie AWS Fargate, Azure Container Apps und Google Cloud Run.

Serverless-Container sind die Brücke zwischen beiden Welten. Cloud Run, App Runner, Azure Container Apps und in Teilen Fargate skalieren Container automatisch auf Null herunter, wenn keine Last anliegt, und ad-hoc wieder hoch, wenn Anfragen kommen. Sie kombinieren das Container-Format mit dem Pay-per-Use-Modell von Serverless. Genau diese Kategorie wird im Mittelstand zunehmend zur Standard-Antwort, weil sie das Portabilitäts-Versprechen von Containern mit den Kostenvorteilen von Serverless verbindet.

Wer diese drei Kategorien klar trennt, kann die folgenden Entscheidungen viel sauberer treffen. Die Diskussion „Serverless oder Container“ ist in Wirklichkeit eine Diskussion über drei Modelle plus deren Kombinationen.

Wann Serverless gewinnt

Es gibt vier Workload-Typen, bei denen Serverless fast immer die wirtschaftlich und operativ überlegene Wahl ist — unabhängig vom Cloud-Anbieter. Diese Muster sollten Sie als Team kennen und in der Architektur-Diskussion sofort wiedererkennen können.

• Sporadische Last mit hohen Leerlauf-PhasenWenn ein Service zwischen einer und tausend Anfragen pro Tag bekommt, und der Tagesverlauf unvorhersehbar ist, ist ein dauerhaft laufender Container reine Geldverschwendung. Beispiel: interne Admin-APIs, B2B-Webhook-Empfänger, gelegentlich genutzte Auswertungs-Funktionen. Lambda oder Cloud Functions kosten hier oft unter zwei Euro im Monat.
• Glue-Code zwischen Cloud-DienstenKlassisch: Datei landet in S3, soll umgewandelt und in einer anderen Bucket abgelegt werden. Oder: eine Queue-Nachricht soll an ein Drittsystem weitergeleitet werden. Diese kurzen, ereignisgetriebenen Funktionen sind das genuine Heimspiel von FaaS — ein Container wäre hier Overkill in Größenordnungen.
• Event-Processing mit unvorhersehbaren SpitzenStreaming-Daten aus IoT-Geräten, Webhook-Bursts nach Marketing-Aktionen, ETL-Bursts in der Nacht. Serverless skaliert in Sekunden auf hunderte oder tausende parallele Instanzen und wieder zurück. Ein Container-Cluster braucht Auto-Scaling-Konfiguration, Health-Checks, Warm-up-Strategien — die Komplexität ist signifikant höher.
• Cron-Jobs und geplante AufgabenNachtliche Reports, stündliche Datenbereinigung, wöchentliche Backup-Verifizierung. Eine Lambda-Funktion mit EventBridge-Scheduler kostet ein paar Cent im Monat und entfällt komplett bei Inaktivität. Ein Cron-Container belegt durchgehend Ressourcen, obwohl er nur einmal am Tag wenige Sekunden arbeitet.

Die operative Dividende ist genauso wichtig wie die Kosten. Bei Serverless entfällt das Patchen der Betriebssystem-Basisschicht, das Skalierungs-Tuning und die Cluster-Wartung. Genau diese Tätigkeiten verschlingen in mittelständischen IT-Teams unverhältnismäßig viel Kapazität. Für Sie als CTO oder IT-Leiter ist das relevant, weil Sie damit Personal für wertschöpfende Arbeit freibekommen.

Wann Container gewinnen

Genauso klar gibt es Workload-Profile, bei denen Container oder Serverless-Container fast immer die bessere Wahl sind. Wer hier auf FaaS setzt, kämpft gegen die Plattform — mit überhöhten Kosten, Workarounds für Limits und schlechter Performance.

• Langläufer-WorkloadsFaaS-Plattformen begrenzen die maximale Ausführungszeit pro Aufruf — AWS Lambda bei 15 Minuten, Azure Functions Consumption bei 10 Minuten, GCP Cloud Functions 2nd Gen bei 60 Minuten. Wenn eine PDF-Generierung, ein Datenexport oder eine ML-Inferenz länger dauert, ist FaaS schlicht ausgeschlossen oder erzwingt komplizierte Chunking-Architekturen.
• GPU- oder Spezial-HardwareMaschinelles Lernen, Video-Encoding, wissenschaftliche Berechnungen brauchen GPUs oder hohe RAM-Mengen. FaaS-Plattformen bieten das nur sehr eingeschränkt und teuer. Container in ECS, Fargate-GPU, AKS-GPU-Knoten oder spezialisierten Diensten wie SageMaker sind hier alternativlos.
• Stateful-WorkloadsWebSocket-Verbindungen, langlebige Datenbank-Pools, In-Memory-Caches mit warmen Zuständen. Serverless ist zustandslos by design — jeder Aufruf könnte auf einer neuen Instanz landen. Container halten den Zustand und sind hier deutlich effizienter.
• Custom-Runtime und ungewöhnliche SprachenFaaS-Plattformen unterstützen eine begrenzte Sprach-Auswahl performant. Wenn Sie Rust, Elixir, Haskell oder eine proprietäre Runtime brauchen, sind Sie mit Containern besser bedient — Sie bringen Ihre Sprache einfach selbst mit.
• Hohe konstante LastEine API mit dauerhaft 50 Anfragen pro Sekunde ist auf FaaS deutlich teurer als auf einem voll ausgelasteten Container — Faktor drei bis sieben sind realistisch. Sobald die Last stabil und vorhersehbar ist, kippt die Kostenrechnung klar zu Containern.

Eine Beobachtung aus der Praxis: Mittelständler, die anfangs „alles Serverless“ planten, landen nach 18 bis 24 Monaten meist bei einer Mischung — die wertschöpfenden Kern-Services laufen in Containern, die Peripherie serverless. Genau diese Hybrid-Architektur beschreiben wir weiter unten.

FaaS-Plattformen: AWS Lambda vs Azure Functions vs GCP Cloud Functions

Die drei großen FaaS-Anbieter ähneln sich oberflächlich, unterscheiden sich aber in Limits, Preisstruktur und Ökosystem-Integration deutlich. Die folgende Übersicht zeigt die für Architektur-Entscheidungen relevanten Eckdaten — Stand Mai 2026, ohne Anspruch auf vollständige Tarif-Vergleichbarkeit.

Eigenschaft	AWS Lambda	Azure Functions	GCP Cloud Functions 2nd Gen
Maximale Ausführungszeit	15 Minuten	10 Min Consumption / 60 Min Premium	60 Minuten (HTTP) / 540 Minuten (Event)
Maximaler Arbeitsspeicher	10 GB	1,5 GB Consumption / 14 GB Premium	32 GB
Maximale vCPU	6 vCPU	1 vCPU Consumption	8 vCPU
Cold-Start-Mitigation	Provisioned Concurrency, SnapStart (Java)	Premium Plan Always-Ready	Min-Instances
Sprach-Unterstützung	Node, Python, Java, .NET, Go, Ruby, Custom-Runtime	Node, Python, Java, .NET, PowerShell, Custom-Handler	Node, Python, Java, Go, .NET, Ruby, PHP
Preis-Modell	Per Request + GB-Sekunden	Per Execution + GB-Sekunden	Per Invocation + GB- und CPU-Sekunden
Freikontingent monatlich	1 Mio Requests + 400.000 GB-Sek	1 Mio Executions + 400.000 GB-Sek	2 Mio Invocations

Praktisch entscheidet meist nicht die FaaS-Plattform selbst, sondern die Tiefe der Ökosystem-Integration. AWS Lambda profitiert massiv vom EventBridge-, S3-, DynamoDB- und Step-Functions-Ökosystem — wenn Ihre Daten dort liegen, ist Lambda fast immer die effizienteste Wahl. Azure Functions glänzt in Microsoft-365- und Dataverse-Integrationen sowie bei Durable Functions für stateful Workflows. Cloud Functions ist besonders stark in Kombination mit BigQuery, Pub/Sub und Firebase. Eine reine Sprachen- oder Limit-Diskussion greift in der Beratungs-Praxis zu kurz.

Container-Plattformen im Vergleich

Auf der Container-Seite ist die Auswahl breiter und unübersichtlicher. Die folgende Übersicht ordnet die wichtigsten Optionen nach Betriebs-Aufwand — von vollständig selbst verwaltet bis fully managed mit Scale-to-Zero.

Plattform	Betriebs-Modell	Stärke	Typischer Einsatz
AWS ECS (mit EC2)	Sie verwalten EC2-Knoten	Volle Kontrolle, günstigste bei hoher Auslastung	Stabile Workloads, kostenoptimiert
AWS Fargate	Serverless-Container, keine Knoten	Pay-per-Task, automatische Skalierung	Wechselnde Lasten, kleine Teams
AWS App Runner	Fully managed, Scale-to-Zero	Einfachste Container-Variante, kein VPC-Detail	Web-APIs ohne Plattform-Komplexität
Azure Container Apps	Serverless-Container, Scale-to-Zero	KEDA-Skalierung, Dapr-Integration	Event-getriebene Mikrodienste
Azure AKS	Managed Kubernetes	Volle Kubernetes-API, hohe Flexibilität	Komplexe Multi-Service-Architekturen
Google Cloud Run	Serverless-Container, Scale-to-Zero	Einfachste Container-Variante mit voller Container-Portabilität	Web-APIs, Job-Worker, Streaming
Google GKE Autopilot	Managed Kubernetes mit Auto-Scaling	Kubernetes ohne Knoten-Verwaltung	Multi-Service mit Standard-Kubernetes-Tooling

Aus unserer Beratungs-Praxis: für die meisten Mittelständler unter 50 Workloads sind Cloud Run, Azure Container Apps und AWS Fargate die produktivsten Plattformen — sie liefern den Großteil des Kubernetes-Nutzens ohne den operativen Aufwand. Echtes Kubernetes (AKS, EKS, GKE Standard) wird erst ab dem Punkt sinnvoll, an dem Sie eigene Operatoren brauchen, Service-Mesh-Funktionen einsetzen oder Multi-Cloud-Portabilität auf Cluster-Ebene wollen. Mehr dazu in unserem Cluster Kubernetes Mittelstand.

Cold-Start-Realität — Mythos und Wahrheit

Cold Starts sind das am meisten überstrapazierte Argument gegen Serverless. Lassen Sie uns die Zahlen nüchtern betrachten. Ein typischer Node.js-Lambda mit 512 MB Speicher hat einen Cold Start zwischen 200 und 600 Millisekunden. Ein Java-Lambda ohne SnapStart kann zwei bis fünf Sekunden brauchen. Ein Python-Cloud-Function mit moderatem Dependency-Set liegt bei 300 bis 800 Millisekunden. Ein Cloud-Run-Container mit kompaktem Image und Min-Instances auf null kommt auf 500 bis 1500 Millisekunden Cold Start.

Für asynchrone Verarbeitung sind diese Werte vollständig unkritisch — eine Queue-Nachricht oder ein nächtlicher Cron-Job verträgt eine halbe Sekunde Verzögerung problemlos. Kritisch werden Cold Starts bei synchronen APIs hinter einem Web-Frontend, weil sie das 99. Perzentil der Antwortzeit deutlich anheben und sich als „die App hängt manchmal“ in der User-Wahrnehmung ausdrücken.

Die Plattformen bieten dafür Gegenmaßnahmen mit unterschiedlichen Trade-offs. Provisioned Concurrency bei AWS Lambda hält eine konfigurierbare Anzahl von Funktions-Instanzen ständig warm — Sie zahlen die Speicher-Sekunden auch ohne Aufrufe. SnapStart für Java-Lambdas friert eine initialisierte JVM ein und taut sie bei Bedarf in unter 200 Millisekunden auf — kostenlos verfügbar, aber Java-spezifisch. Always-Ready-Instanzen im Azure Functions Premium Plan funktionieren analog zu Provisioned Concurrency. Min-Instances bei Cloud Run und Cloud Functions 2nd Gen halten eine Mindestanzahl von Container-Instanzen warm.

Die ehrliche Empfehlung: messen Sie zuerst. In den meisten mittelständischen Workloads sind Cold Starts subjektiv kaum spürbar, sobald die Funktion regelmäßig aufgerufen wird. Erst bei extrem unregelmäßigen Lastmustern mit harten Latenz-Anforderungen lohnt sich die Investition in Provisioned Concurrency oder Min-Instances.

Vendor-Lock-in nüchtern betrachtet

Das Lock-in-Argument gegen Serverless wird in Architektur-Diskussionen oft wie eine Naturkonstante präsentiert — und dann ironischerweise von denselben Teams ignoriert, die parallel Azure SQL, AWS Aurora oder GCP Spanner einsetzen. Eine ehrliche Bestandsaufnahme zeigt: Lock-in entsteht überall, wo Sie tief in Cloud-spezifische Dienste integrieren. Serverless verschärft das, weil die Funktions-Logik selbst an Ereignis-Quellen, Berechtigungs-Modelle und Verwaltungs-Konsolen des Anbieters bindet.

Realistische Risiken lassen sich in drei Stufen einteilen. Stufe eins, niedriges Risiko: die Funktions-Implementierung selbst in Node, Python oder Java ist portabel — Sie können denselben Code prinzipiell auf jeder FaaS-Plattform deployen. Stufe zwei, mittleres Risiko: Trigger-Konfiguration, IAM-Rollen und Infrastructure-as-Code sind anbieterspezifisch — eine Migration kostet Wochen bis Monate. Stufe drei, hohes Risiko: spezifische Dienste wie Step Functions, DynamoDB-Streams, EventBridge oder Cosmos-DB-Change-Feeds sind nicht portabel — eine Migration ist faktisch eine Neuentwicklung.

Container reduzieren das Lock-in nicht so dramatisch, wie oft behauptet. Das Container-Image selbst ist portabel, aber die umliegenden Cloud-Dienste — Load Balancer, Secrets Manager, Service Mesh, Observability-Stack — sind genauso anbieterspezifisch wie bei Serverless. Multi-Cloud-Migrations-Projekte dauern bei beiden Modellen in der Realität sechs bis achtzehn Monate. Wer ernsthaft portabel bleiben will, abstrahiert Anbieter-Dienste über Frameworks (Pulumi, Terraform-Module, Serverless Framework) und akzeptiert dafür höhere Entwicklungs-Komplexität.

Hybrid-Architekturen sind die Realität

Die Frage „Serverless oder Container“ ist in fast allen mittelständischen Architekturen eine falsche Dichotomie. Was Sie wirklich brauchen, ist ein bewusster Mix, in dem jeder Workload-Typ auf der für ihn optimalen Plattform läuft. Eine typische Hybrid-Architektur sieht so aus:

Container-Anteil (60–80 Prozent der Last): synchrone Kern-APIs, B2B-Schnittstellen, Web-Frontends mit konstanter Nutzung, langlebige WebSocket-Dienste, Datenbank-nahe Caching-Layer. Diese laufen auf Cloud Run, Fargate oder Azure Container Apps mit konfiguriertem Auto-Scaling und Min-Instances.

Serverless-Anteil (20–40 Prozent der Last): ereignisgesteuerte Datei-Verarbeitung, Webhook-Empfänger, geplante Jobs, Glue-Code zwischen Diensten, seltene Admin-Operationen, IoT-Stream-Verarbeitung, Mail-Bounces. Diese laufen auf Lambda, Azure Functions oder Cloud Functions.

Der Schlüssel zu einer erfolgreichen Hybrid-Architektur ist eine gemeinsame Observability-Schicht über beide Welten — typischerweise Open-Telemetry mit zentralem Backend in Datadog, New Relic, Grafana Cloud oder dem nativen Anbieter-Stack. Ohne diese Klammer entstehen blinde Flecken im Monitoring, die im Incident-Fall teuer werden.

Kostenbeispiel Side-by-Side

Ein konkretes Rechenbeispiel verdeutlicht, warum die Hybrid-Architektur wirtschaftlich überlegen ist. Betrachten Sie ein typisches Mittelstands-Setup mit drei Workload-Typen: eine Kern-API mit konstanten 30 Anfragen pro Sekunde, ein File-Processor mit 50.000 Datei-Verarbeitungen pro Monat und ein Webhook-Empfänger mit 2 Millionen Aufrufen pro Monat. Die folgende Tabelle zeigt monatliche Kosten in den drei Szenarien — die Zahlen sind aus realen Projekten gemittelt, ohne Anspruch auf exakte Tarif-Genauigkeit.

Workload	Reine Serverless-Architektur	Reine Container-Architektur	Hybrid (empfohlen)
Kern-API (konstant 30 req/s)	520 €	180 €	180 € (Container)
File-Processor (50k/Monat)	35 €	140 €	35 € (Serverless)
Webhook-Empfänger (2M/Monat)	80 €	220 €	80 € (Serverless)
Summe pro Monat	635 €	540 €	295 €
Differenz zur empfohlenen Variante	+115 %	+83 %	—

Der Effekt ist nicht Magie, sondern simple Ökonomie — jeder Workload läuft auf dem für ihn günstigsten Modell. Die reine Serverless-Architektur zahlt für jede einzelne API-Anfrage des Hochlast-Dienstes; die reine Container-Architektur zahlt 24/7 für unausgelastete File-Processor- und Webhook-Container. Für die FinOps-Detail-Betrachtung siehe unseren Cluster zu Cloud-Kosten und FinOps.

Migrations-Pfad: wo anfangen?

Wenn Sie heute klassisch in VMs oder On-Premises betreiben und in eine Serverless-Container-Hybrid-Architektur wandern wollen, empfehlen wir einen vierstufigen Migrations-Pfad. Diese Reihenfolge minimiert Risiken und produziert frühe sichtbare Erfolge.

Stufe eins, Container-First-Lift: verpacken Sie bestehende Services in Container und betreiben Sie sie auf Cloud Run, Fargate oder Azure Container Apps. Sie gewinnen Portabilität, Auto-Scaling und ein modernes Deployment-Modell, ohne den Code grundlegend zu ändern. Diese Stufe dauert typischerweise drei bis sechs Monate für mittlere Architekturen. Wenn Sie Docker noch nicht produktiv einsetzen, beginnen Sie hier — siehe auch Docker vs Podman.

Stufe zwei, Serverless-Peripherie: identifizieren Sie ereignisgesteuerte Randfunktionen — Datei-Verarbeitung, Webhook-Empfänger, Cron-Jobs, Mail-Versand — und implementieren Sie diese gezielt serverless. Diese Stufe reduziert Ihre Container-Last sichtbar und liefert messbare Kosteneinsparungen. Sie dauert je nach Anzahl der Randfunktionen zwei bis vier Monate.

Stufe drei, ereignisgesteuerte Integration: ersetzen Sie synchrone Service-zu-Service-Aufrufe durch ereignisbasierte Kommunikation über EventBridge, Service Bus oder Pub/Sub. Dadurch werden Ihre Container entkoppelt, einzeln skalierbar und unabhängig deploybar. Diese Stufe ist die anspruchsvollste und dauert sechs bis zwölf Monate, weil sie Architektur-Disziplin erfordert.

Stufe vier, kontinuierliche Optimierung: messen Sie monatlich, welche Workloads die FaaS-Limits sprengen (Kosten oder Latenz) und welche Container-Workloads konsistent unter zehn Prozent Auslastung laufen. Verschieben Sie zwischen den Modellen, bis die Kostenkurve flach ist. Diese Stufe endet nie — sie ist Teil des laufenden Cloud-FinOps-Prozesses.

Reepa-Empfehlung für den Mittelstand

Aus der Summe unserer Projekte in deutschen mittelständischen Unternehmen kondensieren wir die folgende Empfehlung. Sie ist bewusst pragmatisch und vermeidet sowohl den Serverless-Hype als auch die Container-Orthodoxie.

Erstens: beginnen Sie mit Serverless-Containern (Cloud Run, App Runner, Azure Container Apps oder Fargate) als Standard für alle neuen synchronen Web-Workloads. Sie kombinieren das Portabilitäts-Versprechen von Containern mit dem Pay-per-Use-Modell von Serverless und minimieren operativen Aufwand.

Zweitens: nutzen Sie reines FaaS (Lambda, Functions, Cloud Functions) bewusst für ereignisgetriebene Glue-Logik, Cron-Jobs und Webhook-Empfänger. Halten Sie diese Funktionen klein, abhängigkeitsarm und in einer der first-class Sprachen der jeweiligen Plattform.

Drittens: reservieren Sie selbstverwaltetes Kubernetes (AKS, EKS, GKE Standard) für Architekturen mit über fünfzig Workloads, eigenen Operatoren oder zwingender Multi-Cloud-Strategie. Unterhalb dieser Schwelle ist der Betriebsaufwand fast immer unverhältnismäßig.

Viertens: investieren Sie in eine einheitliche Observability-Schicht über alle Modelle hinweg — Open-Telemetry-Tracing, zentrale Log-Aggregation, einheitliche Alarmierung. Diese Investition rechnet sich spätestens beim ersten Production-Incident.

Fünftens: messen Sie monatlich Kosten pro Workload und pro Modell. Bewegen Sie Workloads zwischen Serverless und Container, sobald die Auslastungs-Daten das nahelegen. Architektur-Entscheidungen sind nicht statisch — sie sollten Teil Ihres Cloud-FinOps-Prozesses sein.

Häufige Fragen