Serverless-Migration auf AWS: Ein praktischer Leitfaden für Engineering-Teams

Die Frage ist nicht mehr, ob Serverless für Ihr Team relevant ist, sondern wann und wie Sie migrieren. Nach über 15 Jahren AWS-Consulting und dutzenden Serverless-Migrationen habe ich eines gelernt: Der Erfolg hängt weniger von der Technologie ab als von der Migrationsstrategie und dem Verständnis der Eigenheiten serverloser Architekturen.

Dieser Leitfaden richtet sich an Engineering-Teams, die eine Serverless-Migration planen oder bereits mittendrin stecken. Er basiert auf realen Projekterfahrungen und deckt die gesamte Reise ab — von der initialen Bewertung bis zum produktionsreifen Betrieb.

Wann lohnt sich Serverless?

Nicht jeder Workload profitiert von Serverless. Bevor Sie migrieren, sollten Sie ehrlich prüfen, ob Ihr Anwendungsprofil dazu passt.

Serverless ist ideal bei:

Variablem Traffic: Anwendungen mit starken Schwankungen (z. B. E-Commerce mit saisonalen Spitzen) profitieren enorm, weil Sie nur für tatsächliche Nutzung zahlen.
Event-getriebenen Workflows: Datenverarbeitung, Webhooks, Datei-Uploads, IoT-Events — überall dort, wo auf ein Ereignis reagiert wird.
Niedrigem bis mittlerem Dauerlast-Traffic: Bei weniger als 1 Million Requests pro Tag und kurzen Ausführungszeiten (<10 Sekunden) ist Serverless fast immer günstiger als EC2.
Schneller Time-to-Market: Wenn Ihr Team sich auf Geschäftslogik konzentrieren soll statt auf Infrastruktur.

Serverless ist weniger geeignet bei:

Konstantem Hochlast-Traffic: Wenn Ihre Anwendung rund um die Uhr gleichmäßig unter Volllast läuft, sind dedizierte Instanzen mit Savings Plans günstiger.
Langen Laufzeiten: Lambda hat ein Maximum von 15 Minuten. Für Batch-Jobs, die Stunden laufen, brauchen Sie Fargate oder Step Functions mit verteilter Verarbeitung.
Extrem latenzempfindlichen Workloads: Cold Starts (dazu gleich mehr) können bei seltenen Aufrufen die Latenz in den dreistelligen Millisekundenbereich treiben.

Die Kosten-Schwelle: Als Faustregel gilt: Ab etwa 30 Millionen Lambda-Invocations pro Monat bei durchschnittlich 500ms Laufzeit und 512 MB Memory wird ein Vergleich mit EC2/Fargate interessant. Darunter gewinnt Serverless fast immer.

Migrationsstrategie: Das Strangler Fig Pattern

Der größte Fehler, den ich bei Serverless-Migrationen sehe, ist der Versuch, alles auf einmal umzubauen. Stattdessen empfehle ich das Strangler Fig Pattern: Sie wickeln Ihren bestehenden Monolithen schrittweise mit neuen Serverless-Komponenten ein, bis der Monolith am Ende überflüssig wird.

Schritt 1: API Gateway als Fassade

Stellen Sie ein API Gateway vor Ihren bestehenden Monolithen. Anfangs leitet es 100 % der Requests an den Monolithen weiter. Dann migrieren Sie Route für Route.

# API Gateway mit HTTP-Integration zum bestehenden ALB erstellen
aws apigatewayv2 create-api \
  --name "my-app-migration" \
  --protocol-type HTTP

# Default-Route zum bestehenden ALB
aws apigatewayv2 create-integration \
  --api-id abc123 \
  --integration-type HTTP_PROXY \
  --integration-uri "arn:aws:elasticloadbalancing:eu-central-1:123456789012:listener/app/my-alb/50dc6c495c0c9188/..."
  --integration-method ANY

Schritt 2: Erste Route migrieren

Wählen Sie eine Route mit wenig Abhängigkeiten und klarer Eingabe/Ausgabe. Ein guter Kandidat ist oft ein lesender Endpunkt wie /api/products/{id}.

Schritt 3: Schrittweise erweitern

Migrieren Sie weitere Routen in der Reihenfolge ihrer Komplexität. Nutzen Sie Feature Flags oder gewichtetes Routing, um Traffic schrittweise umzuleiten:

# Gewichtetes Routing: 90% Monolith, 10% Lambda
aws apigatewayv2 create-route \
  --api-id abc123 \
  --route-key "GET /api/products/{id}" \
  --target "integrations/lambda-integration-id"

Schritt 4: Monolith abschalten

Wenn alle Routen migriert sind, können Sie den Monolithen herunterfahren. Das klingt einfach, aber planen Sie Zeit für das Entfernen der alten Infrastruktur und das Aktualisieren von Monitoring und Alarmen ein.

Lambda Best Practices

Lambda ist das Herzstück jeder Serverless-Architektur auf AWS. Diese Best Practices basieren auf realen Produktionserfahrungen.

Cold Starts minimieren

Cold Starts entstehen, wenn AWS eine neue Lambda-Ausführungsumgebung hochfahren muss. Die Dauer hängt von der Runtime, der Paketgröße und der VPC-Konfiguration ab.

Typische Cold-Start-Zeiten:

Node.js / Python (ohne VPC): 100-300 ms
Java / .NET (ohne VPC): 500-2000 ms
Beliebige Runtime mit VPC: +200-500 ms (dank Hyperplane deutlich besser als früher)

Gegenmaßnahmen:

Provisioned Concurrency für latenzempfindliche Funktionen. Kostet extra, eliminiert aber Cold Starts komplett.
Paketgröße minimieren. Nutzen Sie Tree-Shaking, laden Sie nur die AWS SDK-Clients, die Sie brauchen, und vermeiden Sie unnötige Dependencies.
Initialisierung außerhalb des Handlers. Datenbankverbindungen, SDK-Clients und Konfiguration gehören in den globalen Scope — nicht in die Handler-Funktion.

# Provisioned Concurrency für eine Funktion konfigurieren
aws lambda put-provisioned-concurrency-config \
  --function-name my-api-handler \
  --qualifier prod \
  --provisioned-concurrent-executions 10

VPC-Konfiguration

Grundregel: Platzieren Sie Lambda nur dann in einer VPC, wenn es notwendig ist — etwa für den Zugriff auf RDS, ElastiCache oder andere VPC-interne Ressourcen. Für Lambda-Funktionen, die nur mit AWS-Diensten wie DynamoDB, S3 oder SQS kommunizieren, ist keine VPC nötig.

Wenn Sie eine VPC brauchen, stellen Sie sicher, dass Sie mindestens zwei Subnets in verschiedenen Availability Zones konfigurieren, damit Lambda bei einem AZ-Ausfall weiterhin funktioniert.

Memory-Tuning

Ein häufig übersehener Punkt: Lambda weist CPU proportional zum konfigurierten Memory zu. Mehr Memory bedeutet mehr CPU — und oft eine kürzere Ausführungszeit, die die höheren Memory-Kosten überkompensiert.

So finden Sie die optimale Konfiguration:

Nutzen Sie AWS Lambda Power Tuning, ein Open-Source-Tool, das Ihre Funktion mit verschiedenen Memory-Konfigurationen testet und die kostenoptimale Einstellung empfiehlt.

# Lambda Power Tuning über SAR deployen
aws serverlessrepo create-cloud-formation-change-set \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM

In meiner Erfahrung ist die Standardkonfiguration von 128 MB fast nie optimal. Für typische API-Handler liegt der Sweet Spot oft bei 512-1024 MB.

EventBridge für Event-Driven Architecture

EventBridge ist der zentrale Baustein für lose gekoppelte Serverless-Architekturen. Statt Services direkt miteinander zu verbinden, publizieren sie Events auf einen Bus, und andere Services abonnieren die Events, die sie interessieren.

Architekturprinzip: Stellen Sie sich EventBridge als den zentralen Nervenstrang Ihrer Anwendung vor. Wenn ein Kunde eine Bestellung aufgibt, publiziert der Order-Service ein order.created-Event. Der Payment-Service, der Inventory-Service und der Notification-Service reagieren unabhängig voneinander darauf.

# Eigenen Event Bus erstellen
aws events create-event-bus --name "my-app-events"

# Regel für order.created Events
aws events put-rule \
  --event-bus-name "my-app-events" \
  --name "order-created-to-payment" \
  --event-pattern '{
    "source": ["com.myapp.orders"],
    "detail-type": ["order.created"]
  }'

# Lambda als Target hinzufügen
aws events put-targets \
  --event-bus-name "my-app-events" \
  --rule "order-created-to-payment" \
  --targets '[{"Id":"payment-handler","Arn":"arn:aws:lambda:eu-central-1:123456789012:function:process-payment"}]'

Best Practices für Events:

Verwenden Sie eine klare Namenskonvention: {company}.{domain} als Source, {entity}.{action} als Detail-Type.
Entwerfen Sie Events so, dass sie alle nötigen Informationen enthalten. Konsumenten sollten keine zusätzlichen API-Aufrufe brauchen, um ein Event zu verarbeiten.
Versionieren Sie Ihre Event-Schemas mit dem EventBridge Schema Registry.
Nutzen Sie Archive und Replay für Debugging und Disaster Recovery.

Step Functions für Orchestrierung

Wenn Sie mehrere Lambda-Funktionen koordinieren müssen — etwa für einen mehrstufigen Bestellprozess — greifen Sie zu Step Functions statt zu direkter Lambda-zu-Lambda-Verkettung.

Warum Step Functions statt direkter Verkettung?

Eingebautes Retry und Error Handling: Konfigurieren Sie Retry-Strategien und Fallback-Pfade deklarativ.
Visuelles Debugging: Die Step Functions Console zeigt den exakten Zustand jeder Ausführung.
Timeouts und Parallelisierung: Lassen Sie Schritte parallel laufen und definieren Sie Timeouts pro Schritt.
SDK-Integrationen: Über 200 AWS-Dienste können direkt aus Step Functions aufgerufen werden, ohne eine Lambda-Funktion dazwischen.

Express vs. Standard Workflows:

Standard Workflows für lang laufende Prozesse (bis 1 Jahr), bei denen Sie den Zustand jedes Schritts persistieren müssen. Abrechnung pro Zustandsübergang.
Express Workflows für kurze, hochfrequente Abläufe (bis 5 Minuten). Abrechnung nach Dauer und Speicher — deutlich günstiger bei hohem Durchsatz.

Für die meisten API-Orchestrierungsszenarien sind Express Workflows die richtige Wahl. Verwenden Sie Standard Workflows für Prozesse wie Order Fulfillment, die über Stunden oder Tage laufen können.

DynamoDB vs. Aurora Serverless

Die Datenbankwahl ist eine der wichtigsten Entscheidungen bei einer Serverless-Migration.

DynamoDB ist die nativere Wahl in einer Serverless-Architektur:

Kein Connection Management nötig (HTTP-basierte API)
Skaliert automatisch auf Millionen von Requests
On-Demand-Modus eliminiert Kapazitätsplanung
Ideal für Key-Value- und Document-Zugriffsmuster

Aurora Serverless v2 ist die bessere Wahl, wenn:

Sie komplexe relationale Abfragen mit Joins brauchen
Ihre Anwendung bereits stark auf SQL aufgebaut ist
Transaktionskonsistenz über mehrere Tabellen essenziell ist

Meine Empfehlung: Für neue Serverless-Anwendungen starten Sie mit DynamoDB und dem Single-Table-Design-Pattern. Für Migrationen bestehender Anwendungen mit relationaler Datenbank ist Aurora Serverless v2 oft der pragmatischere Weg, weil Sie den Datenzugriffscode nicht komplett umschreiben müssen.

Achtung bei Lambda + RDS/Aurora: Nutzen Sie unbedingt den RDS Proxy, um Connection Pooling zu ermöglichen. Ohne Proxy kann Lambda bei hoher Parallelität hunderte Datenbankverbindungen öffnen und die Datenbank überlasten.

# RDS Proxy erstellen
aws rds create-db-proxy \
  --db-proxy-name my-app-proxy \
  --engine-family POSTGRESQL \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"arn:aws:secretsmanager:eu-central-1:123456789012:secret:my-db-creds","IAMAuth":"REQUIRED"}]' \
  --role-arn arn:aws:iam::123456789012:role/rds-proxy-role \
  --vpc-subnet-ids subnet-0abc123 subnet-0def456

Monitoring mit CloudWatch und X-Ray

Serverless-Architekturen sind von Natur aus verteilt, was das Monitoring komplexer macht. Ohne eine durchdachte Observability-Strategie wird das Debugging zum Albtraum.

CloudWatch Metriken, die Sie überwachen sollten:

Errors und Throttles pro Lambda-Funktion
Duration (p99) — nicht nur der Durchschnitt, sondern das 99. Perzentil
ConcurrentExecutions — um Throttling frühzeitig zu erkennen
Iterator Age bei Kinesis/DynamoDB Streams — zeigt, wie weit der Consumer hinterherhinkt

# Alarm für Lambda-Fehler einrichten
aws cloudwatch put-metric-alarm \
  --alarm-name "my-function-errors" \
  --metric-name Errors \
  --namespace AWS/Lambda \
  --dimensions Name=FunctionName,Value=my-api-handler \
  --statistic Sum \
  --period 300 \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:eu-central-1:123456789012:alerts"

X-Ray für verteiltes Tracing:

Aktivieren Sie X-Ray für alle Lambda-Funktionen, API Gateways und Step Functions. Das ermöglicht es, einen einzelnen Request durch alle beteiligten Services zu verfolgen und Bottlenecks zu identifizieren.

# X-Ray Tracing für eine Lambda-Funktion aktivieren
aws lambda update-function-configuration \
  --function-name my-api-handler \
  --tracing-config Mode=Active

Structured Logging: Verwenden Sie JSON-formatierte Logs mit einer Correlation ID, die über alle Services hinweg propagiert wird. AWS bietet mit Powertools for Lambda (verfügbar für Python, TypeScript, Java und .NET) eine hervorragende Bibliothek, die Structured Logging, Tracing und Metriken in einem Paket bündelt.

Kostenkontrolle in Serverless-Architekturen

„Serverless heißt nicht kostenlos." Diesen Satz sage ich in jedem Projekt mindestens einmal. Obwohl das Pay-per-Use-Modell grundsätzlich kosteneffizient ist, gibt es Fallstricke.

Die häufigsten Kostenfallen:

Übermäßiges Logging: CloudWatch Logs kosten 0,50 USD pro aufgenommenem Gigabyte. Bei hohem Durchsatz mit ausführlichem Logging summiert sich das schnell. Setzen Sie Log-Level in Produktion auf WARN oder ERROR.
Provisioned Concurrency ohne Notwendigkeit: Nur für Funktionen mit echten Latenzanforderungen einsetzen — nicht pauschal.
DynamoDB On-Demand bei hohem, stabilem Durchsatz: Ab einem gewissen Volumen ist Provisioned Capacity mit Auto Scaling günstiger.

Budgets und Alarme einrichten:

# CloudWatch Alarm für Lambda-Kosten
aws ce create-anomaly-monitor \
  --anomaly-monitor '{
    "MonitorName": "ServerlessAnomalyMonitor",
    "MonitorType": "DIMENSIONAL",
    "MonitorDimension": "SERVICE"
  }'

Nutzen Sie den Cost Explorer, um Ihre Serverless-Kosten nach Funktion aufzuschlüsseln. Taggen Sie jede Lambda-Funktion, jede DynamoDB-Tabelle und jede SQS-Queue mit einem konsistenten Tagging-Schema (mindestens project, environment, team), damit Sie die Kosten zuordnen können.

Fazit: Migration als iterativer Prozess

Eine Serverless-Migration ist kein Sprint, sondern ein Marathon. Widerstehen Sie der Versuchung, alles auf einmal umzubauen. Das Strangler Fig Pattern hat sich in der Praxis bewährt, weil es Risiko minimiert und dem Team erlaubt, Serverless-Kompetenz schrittweise aufzubauen.

Starten Sie mit einem einzelnen, klar abgegrenzten Workload. Sammeln Sie Erfahrung mit Lambda, EventBridge und Step Functions. Etablieren Sie Monitoring und Kostenkontrolle von Anfang an. Und dann erweitern Sie schrittweise.

Die technische Migration ist dabei oft der einfachere Teil. Die eigentliche Herausforderung liegt im Mindset-Shift: weg von Server-zentrischem Denken, hin zu event-getriebenen, funktionsbasierten Architekturen. Geben Sie Ihrem Team die Zeit und die Schulung, die es braucht.

Wenn Sie Unterstützung bei der Planung oder Umsetzung Ihrer Serverless-Migration benötigen, stehe ich Ihnen gerne zur Verfügung. In einem unverbindlichen Erstgespräch bewerten wir gemeinsam, welche Workloads für Serverless geeignet sind und wie der optimale Migrationspfad aussieht.