Claude Code Serverless: AWS Lambda, Azure Functions und Cloud-Funktionen entwickeln mit KI

Serverless ist die Architektur, bei der du keine Server verwaltest — und trotzdem alles auf Servern läuft. Der Witz klingt abgenutzt, trifft aber einen echten Punkt: Serverless verschiebt Komplexität vom Infrastruktur-Management in die Funktionslogik und das Cloud-Setup. AWS Lambda, Azure Functions, Google Cloud Functions — alle drei haben ihre eigenen Eigenheiten, Deployment-Pipelines und Debugging-Werkzeuge.

Claude Code macht Serverless-Entwicklung schneller, weil es den gesamten Kontext auf einmal sieht: Handler-Code, SAM-Template, IAM-Policy, Environment-Variablen. Kein Tab-Switching zwischen Konsole und IDE, kein manuelles Zusammensetzen von IAM-Fehlern und Code-Logik. Dieser Artikel zeigt, wie das konkret aussieht — provider-spezifisch, mit echten Befehlen.

1. Serverless-Grundlagen und Architektur: FaaS, Event-Driven, Cold Start

Function-as-a-Service (FaaS) ist das Kernkonzept hinter Serverless: du deployst einzelne Funktionen, nicht Anwendungen. Eine Funktion wird durch ein Ereignis ausgelöst — einen HTTP-Request, eine Queue-Nachricht, einen Datenbank-Trigger, einen Cron-Job — führt aus und beendet sich. Die Infrastruktur startet, skaliert und hält an, ohne dass du eingreifen musst.

Das klingt einfach. In der Praxis entstehen schnell Fragen: Wie strukturiere ich Handler, die wiederverwendbar sind? Wie verwalte ich Shared Dependencies zwischen Funktionen? Wie debugge ich einen Fehler, der nur unter Last auftritt? Claude Code hilft hier nicht nur beim Schreiben von Code, sondern beim Durchdenken der Architektur.

claude "Ich baue eine Event-Driven-Architektur mit drei Lambda-Funktionen:
1. HTTP-Handler für User-Requests
2. Async-Processor für schwere Berechnungen via SQS
3. Scheduler für nächtliche Reports

Wie strukturiere ich den Code sinnvoll, damit Shared Logic nicht dupliziert wird?"

Claude Code analysiert diese Anforderung und empfiehlt typischerweise eine Mono-Repo-Struktur mit einem shared/-Verzeichnis für gemeinsame Logik, separaten functions/-Ordnern pro Lambda und einem einzigen Build-Step, der die Abhängigkeiten korrekt bündelt.

Cold Starts verstehen

Der größte Mythos in Serverless ist, dass Cold Starts unvermeidlich schlimm sind. In Wirklichkeit hängt ihre Dauer von drei Faktoren ab: der Laufzeit (Node.js ist schneller als Java), der Paketgröße und ob du Provisioned Concurrency nutzt. Claude Code hilft, diese Faktoren für deinen spezifischen Fall zu analysieren:

claude "Meine Lambda-Funktion hat Cold Starts von 3-4 Sekunden.
Analysiere package.json und handler.ts und erkläre, wo die Zeit verloren geht."

Event-Driven-Architekturen haben eine weitere Eigenheit: Fehler propagieren anders als in synchronen Systemen. Wenn eine SQS-Nachricht fehlschlägt, landet sie in der Dead Letter Queue — aber nur wenn du die DLQ konfiguriert hast. Claude Code prüft auf genau solche Konfigurationslücken, die im Alltag leicht vergessen werden.

2. AWS Lambda mit Claude Code: Handler, Layers, SAM CLI

AWS Lambda ist der älteste und reifste Serverless-Provider. Das bedeutet: viele Features, viele Konfigurationsoptionen und eine Lernkurve, die steiler ist als sie sein müsste. SAM CLI (Serverless Application Model) ist das offizielle Werkzeug für lokales Testing und Deployment — aber das YAML-Template-Format ist fehleranfällig und die Fehlermeldungen sind oft kryptisch.

Claude Code liest SAM-Templates und erkennt Probleme, die du erst beim Deployment siehst:

claude "Prüfe dieses SAM-Template auf typische Konfigurationsfehler:
- Fehlende IAM-Permissions
- Falsche Event-Source-Konfiguration
- Ungenügende Timeout-Werte
- Fehlende Environment-Variablen" < template.yaml

Handler-Struktur für TypeScript

Ein produktionsreifer Lambda-Handler in TypeScript folgt einem Muster, das Claude Code direkt generieren kann:

claude "Erstelle einen TypeScript Lambda-Handler für API Gateway Proxy Integration mit:
- Zod-Validation für den Request-Body
- Strukturiertem Error-Handling mit HTTP-Status-Codes
- Logging via AWS Lambda Powertools
- Korrektem CORS-Header-Handling"

Das Ergebnis enthält nicht nur den Handler-Code, sondern auch den zugehörigen SAM-Eintrag, die nötigen IAM-Statements und eine Empfehlung für die Timeout-Konfiguration basierend auf der erwarteten Logik.

Lambda Layers für Shared Dependencies

Lambda Layers lösen das Problem duplizierter Abhängigkeiten zwischen Funktionen. Die Konfiguration ist aber nicht trivial — Verzeichnisstruktur, ARN-Referenzierung im Template und Update-Strategie müssen stimmen.

claude "Ich habe folgende npm-Pakete, die ich als Lambda Layer teilen möchte:
- aws-lambda-powertools (Logging, Tracing, Metrics)
- zod (Validation)
- @aws-sdk/client-dynamodb

Erstelle die korrekte Layer-Struktur, das SAM-Template und erkläre die Update-Strategie."

Lokales Testing mit SAM CLI

SAM CLI ermöglicht lokales Ausführen von Lambda-Funktionen — aber das Setup und die Event-Formate sind oft unklar. Claude Code generiert korrekte Test-Events:

claude "Generiere ein SAM CLI Test-Event für einen POST-Request an /api/users
mit JSON-Body {name: 'Test', email: 'test@example.com'} und Authorization-Header.
Das Event muss dem API Gateway Proxy-Format entsprechen."

Mit dem generierten Event kannst du lokal testen: sam local invoke MyFunction --event event.json — ohne Deployment, ohne echte AWS-Kosten während der Entwicklung.

3. Azure Functions entwickeln: C#, Python, TypeScript, Bindings, Durable Functions

Azure Functions ist Microsofts Antwort auf Lambda — mit einem eigenen Konzept, das Lambda-Entwicklern zunächst fremd ist: Bindings. Statt explizit AWS-SDK-Calls zu schreiben, deklarierst du Input- und Output-Bindings in einer Konfigurationsdatei, und Azure Functions verbindet die Datenquellen automatisch.

Das ist elegant, wenn es funktioniert. Wenn es nicht funktioniert, sind die Fehlermeldungen oft kryptisch. Claude Code liest function.json und den Handler-Code gleichzeitig und erkennt Inkompatibilitäten:

claude "Meine Azure Function gibt keinen Output in den Cosmos DB Output Binding.
Analysiere function.json und index.ts und erkläre was fehlt." 

C#-Funktionen mit isoliertem Worker-Modell

Das isolierte Worker-Modell ist seit Azure Functions v4 der empfohlene Ansatz für .NET — aber die Migration vom In-Process-Modell hat Fallstricke. Claude Code kennt beide Modelle und hilft bei der Migration:

claude "Migriere diese Azure Function vom In-Process-Modell
auf das isolierte Worker-Modell (.NET 8).
Achte besonders auf:
- IFunctionFilter statt FunctionInvocationFilter
- OutputBinding<T> statt return-Typ
- Korrekte Program.cs Konfiguration"

Python-Funktionen mit v2 Programming Model

Das neue Python Programming Model (v2) ersetzt function.json durch Dekoratoren — ähnlich wie Flask oder FastAPI. Claude Code generiert idiomatische v2-Funktionen:

claude "Schreibe eine Azure Function in Python (v2 Programming Model) die:
- HTTP POST auf /api/process empfängt
- Eine Nachricht in Azure Service Bus schreibt
- Bei Fehler in Table Storage loggt
- Korrekte Typen und Fehlerbehandlung hat"

Durable Functions für lange Workflows

Durable Functions sind Azure's Antwort auf das Problem langer, zustandsbehafteter Workflows in Serverless. Das Konzept — Orchestrator, Activity, Entity — ist mächtig aber nicht intuitiv. Claude Code erklärt nicht nur das Konzept, sondern implementiert direkt:

claude "Implementiere einen Durable Functions Workflow in TypeScript für:
1. HTTP-Trigger startet den Workflow
2. Orchestrator ruft 3 Activity Functions parallel auf
3. Warte auf menschliche Genehmigung (Human Interaction Pattern)
4. Nach Genehmigung: finaler Activity-Aufruf
5. Status-Endpoint für Frontend-Polling"

Das generierte Ergebnis enthält alle vier Funktionstypen (Orchestrator, drei Activities, HTTP-Client-Trigger) plus den Status-Endpoint und die korrekte host.json-Konfiguration für Durable Functions.

4. Google Cloud Functions und Firebase: Triggers, Pub/Sub, Firestore

Google Cloud Functions (GCF) und Firebase Functions teilen die Laufzeitinfrastruktur, haben aber unterschiedliche Trigger-Systeme. Firebase Functions sind tighter mit der Firebase-Plattform integriert — Firestore-Trigger, Auth-Events, Storage-Events — während GCF breiter in die Google Cloud integriert ist.

Claude Code kennt beide Systeme und hilft, den richtigen Ansatz für dein Setup zu wählen:

claude "Ich nutze Firebase Auth + Firestore für meine App.
Soll ich Firebase Functions oder Google Cloud Functions nutzen?
Was sind die konkreten Unterschiede für mein Setup?"

Firestore-Trigger für reaktive Workflows

Firestore-Trigger sind eine der stärksten Firebase-Funktionen — Funktionen die automatisch ausgeführt werden, wenn sich Dokumente ändern. Die Konfiguration ist einfach, aber Fallstricke lauern bei rekursiven Triggern und bei der Datenkonsistenz:

claude "Schreibe eine Firebase Function die auf Firestore-Dokument-Schreibvorgänge
in /orders/{orderId} reagiert und:
- Nur bei Status-Änderungen zu 'confirmed' ausgeführt wird
- Eine E-Mail-Benachrichtigung sendet
- Den Lagerbestand in einem anderen Dokument reduziert
- Rekursive Trigger durch before/after-Vergleich verhindert"

Pub/Sub für Event-Driven Pipelines

Google Cloud Pub/Sub ist das Message-System hinter vielen GCP-Architektur-Patterns. Funktionen als Subscriber zu konfigurieren, mit korrektem Acknowledgment-Handling, ist nicht trivial — besonders wenn Nachrichten idempotent verarbeitet werden müssen:

claude "Erstelle eine Google Cloud Function als Pub/Sub Subscriber für ein
'user-events'-Topic. Die Funktion soll:
- Base64-encodierte Nachrichten korrekt dekodieren
- Idempotentes Processing mit Deduplizierungs-Key sicherstellen
- Bei Verarbeitungsfehlern die Nachricht für Retry zurückhalten (NACK)
- Nach 3 Fehlversuchen in BigQuery für Analyse speichern"

2nd Generation Cloud Functions

Cloud Run Functions (die neue Bezeichnung für GCF 2nd Gen) basieren auf Cloud Run und bieten längere Timeouts, mehr Speicher und Concurrency pro Instanz. Claude Code hilft bei der Migration und erklärt, wann die 2nd Gen sinnvoll ist:

claude "Meine Cloud Function braucht manchmal bis zu 8 Minuten für eine Dateiverarbeitung.
Soll ich auf 2nd Generation migrieren? Was ändert sich im Code und im Deploy-Prozess?"

5. API Gateway und HTTP-Endpoints: REST API, API Gateway, CORS

Serverless-Funktionen sind selten allein — meistens stecken sie hinter einem API Gateway, das HTTP-Requests entgegennimmt und an die richtige Funktion weiterleitet. Das API Gateway ist auch das erste, was Nutzer sehen, wenn etwas schiefgeht. CORS-Fehler, fehlerhafte Routing-Konfigurationen und missing Authorization-Handler sind die häufigsten Probleme.

AWS API Gateway v2 (HTTP API)

AWS hat zwei API Gateway-Produkte: das ältere REST API und das neuere HTTP API (v2). HTTP API ist günstiger, schneller und für die meisten Lambda-Anwendungsfälle ausreichend. Claude Code hilft bei der Wahl und der Konfiguration:

claude "Erkläre den Unterschied zwischen API Gateway REST API und HTTP API
für meinen Use Case: JWT-Auth, mehrere Lambda-Funktionen, CORS für *.example.com.
Generiere das SAM-Template für die empfohlene Variante."

CORS korrekt konfigurieren

CORS ist eine der häufigsten Fehlerquellen bei Serverless-APIs. Das Problem: CORS muss sowohl im API Gateway als auch im Lambda-Response-Header konfiguriert sein — und beide müssen konsistent sein. Claude Code prüft beides gleichzeitig:

claude "Meine React-App auf https://app.example.com bekommt CORS-Fehler
beim Aufruf meiner Lambda-Funktion. Analysiere:
1. Die API Gateway CORS-Konfiguration in template.yaml
2. Die Response-Headers in meinem Handler
Wo ist der Widerspruch und wie behebe ich ihn?"

Typischer Befund: Das API Gateway erlaubt den Origin, aber der Lambda-Handler gibt beim OPTIONS Preflight-Request keinen Access-Control-Allow-Origin-Header zurück — oder gibt ihn zurück, aber mit hartkodierter URL statt dem Origin-Header des Requests.

JWT-Authorizer für Auth0 oder Cognito

Ein API Gateway JWT-Authorizer validiert Tokens, bevor die Lambda-Funktion aufgerufen wird. Das spart Ausführungszeit und Kosten. Die Konfiguration unterscheidet sich leicht zwischen Auth0 und Cognito:

claude "Konfiguriere einen API Gateway v2 JWT Authorizer für Auth0.
Mein Auth0-Domain ist auth.example.com, Audience ist 'my-api'.
Zeige das SAM-Template und erkläre, wie der Lambda-Handler
auf die Claims im Event zugreift."

Custom Domain und Stage Management

API Gateway erzeugt von Haus aus kryptische URLs. Eine Custom Domain (api.example.com) mit Staging (api.example.com/v1/) zu konfigurieren, erfordert ACM-Zertifikat, Route53-Eintrag und API-Mapping — alles gleichzeitig richtig:

claude "Erstelle das SAM-Template für eine Custom Domain api.example.com
mit zwei Stages: /v1 (prod Lambda-Alias) und /dev (dev Lambda-Alias).
Das ACM-Zertifikat arn:aws:acm:... ist bereits vorhanden."

6. Cold Starts optimieren und Monitoring: CloudWatch, X-Ray, OpenTelemetry

Eine Lambda-Funktion, die in der Entwicklung 200 ms braucht, kann in Produktion 3 Sekunden Cold Start haben. Das ist kein Bug — es ist das Systemverhalten. Aber es ist steuerbar: durch Bundle-Optimierung, Provisioned Concurrency, sorgfältiges Dependency-Management und smarte Initialisierung.

Bundle-Analyse mit Claude Code

Der größte Hebel für Cold-Start-Reduktion ist die Bundle-Größe. Ein kleineres Bundle lädt schneller — logisch. Aber welche Abhängigkeiten wirklich groß sind, ist ohne Analyse nicht offensichtlich:

claude "Analysiere das Build-Output meiner Lambda-Funktion.
Welche Pakete machen mehr als 10% der Bundle-Größe aus?
Welche können durch schlankere Alternativen ersetzt werden?" < bundle-stats.json

Claude Code identifiziert häufig: moment.js (ersetzbar durch date-fns oder natives Intl), lodash (ersetzbar durch gezielte Imports oder native Methoden), volle AWS SDK v2-Imports statt modularisiertem SDK v3.

Initialisierung außerhalb des Handlers

Code außerhalb der Handler-Funktion wird beim Cold Start einmal ausgeführt und dann für alle nachfolgenden warmen Invocations wiederverwendet. Das ist der richtige Ort für teure Initialisierungen — Datenbankverbindungen, SDK-Clients, Konfigurationsladen:

claude "Refaktorisiere diesen Lambda-Handler: alle teure Initialisierungen
(DynamoDB-Client, Secrets-Manager-Lookup, Konfigurationsvalidierung)
müssen außerhalb der Handler-Funktion stehen.
Achte darauf, dass Fehler bei der Initialisierung den Container sofort beenden."

CloudWatch und strukturiertes Logging

Lambda loggt automatisch nach CloudWatch. Aber unstrukturiertes Logging macht CloudWatch-Suchen schwer. Strukturiertes JSON-Logging mit Correlation-IDs ermöglicht gezielte Abfragen:

claude "Implementiere strukturiertes Logging für meine Lambda-Funktion mit:
- JSON-Format für CloudWatch Insights
- Request-ID als Correlation-ID in jedem Log-Eintrag
- Log-Level aus Environment-Variable konfigurierbar
- Automatisches Masking sensibler Felder (email, token, password)"

AWS X-Ray Tracing

X-Ray ermöglicht Distributed Tracing über mehrere Lambda-Funktionen und AWS-Services hinweg. Die Instrumentierung ist überschaubar, aber die AWS SDK v3-Integration hat sich gegenüber v2 geändert:

claude "Instrumentiere meine Lambda-Funktion mit X-Ray Tracing:
- Aktiviere automatisches Tracing für DynamoDB und S3 Calls
- Füge Custom Subsegments für meine Geschäftslogik ein
- Zeige die korrekte SAM-Konfiguration für AWS SDK v3"

OpenTelemetry als Provider-agnostische Alternative

Wenn du nicht an CloudWatch/X-Ray gebunden sein willst und Datadog, Jaeger oder Grafana Tempo nutzt, ist OpenTelemetry die richtige Wahl. Claude Code konfiguriert den OTel Lambda Layer:

claude "Konfiguriere OpenTelemetry für meine AWS Lambda-Funktion.
Ziel ist Datadog als Backend.
Ich will den AWS ADOT Lambda Layer nutzen und brauche:
- Korrekte SAM-Konfiguration für den Layer
- Environment-Variablen für Datadog-Exporter
- Automatisches Tracing ohne Code-Änderungen im Handler"

Alarmierung bei Cold Start Spitzen

Provisioned Concurrency ist teuer. Die Alternative: CloudWatch-Alarme, die dir sagen, wenn Cold Starts problematisch werden — ohne dauerhaft Kapazität vorzuhalten:

claude "Erstelle CloudWatch-Alarme für meine Lambda-Funktion die mich alarmieren wenn:
- P99-Latenz über 2 Sekunden steigt
- Cold-Start-Rate über 5% liegt (Init Duration Metrik)
- Error-Rate über 1% steigt
Zeige das CloudFormation-Template für diese drei Alarme mit SNS-Topic."

Monitoring ist nicht das Ende — es ist der Anfang der Optimierung. Mit den richtigen Metriken siehst du, wo deine Serverless-Architektur wirklich Zeit verliert: ob in Cold Starts, in externen API-Calls, in der Datenbankabfrage oder in der Geschäftslogik selbst. Claude Code liest Traces und Metriken und gibt konkrete Optimierungsempfehlungen — priorisiert nach Auswirkung.

• Cold Start > 1s: Bundle-Analyse, Initialisierung auslagern, Provisioned Concurrency prüfen
• Error-Rate steigt: DLQ konfigurieren, Retry-Logik prüfen, Timeout-Werte anpassen
• Kosten überraschen: Memory-Konfiguration optimieren (oft läuft Lambda mit zu viel RAM), Cold-Start-Rate und Request-Muster analysieren
• Latenz-Spitzen: X-Ray-Traces lesen, Downstream-Bottleneck identifizieren, Caching prüfen

Zwei verwandte Artikel die auf diesem Thema aufbauen:

• Claude Code Debugging — wie du Fehler in Lambda-Funktionen systematisch analysierst
• Claude Code für Unternehmen — Deployment, Zugriffskontrolle und Team-Workflows auf Unternehmensebene