Serverless & Cloud 2. Mai 2026 9 Min. Lesezeit

Claude Code Serverless Functions 2026: Vercel, AWS Lambda und KI-Workflows

Serverless und KI sind ein natürliches Paar — sofern man die Eigenheiten beider Welten kennt. Dieser Artikel zeigt, wann Vercel Edge Functions, AWS Lambda und Cloudflare Workers für Claude-gestützte Workflows die richtige Wahl sind, welche Fallstricke es gibt und wie du Cold Starts, Kosten und Execution-Limits im Griff behältst.

1. Warum Serverless perfekt zu AI-Workflows passt

Ein typischer KI-Task ist kein Dauerprozess — er wird durch ein Ereignis ausgelöst: eine neue E-Mail trifft ein, ein Webhook feuert, ein Nutzer schickt eine Anfrage, ein Cron-Timer läuft ab. Genau dieses Event-driven-Muster ist das Kerndesign von Serverless Functions. Statt einen VPS rund um die Uhr hochzuhalten, der 95 % der Zeit wartet, zahlst du nur für tatsächliche Ausführungszeit.

Ideal für

Reaktive AI-Tasks

Webhook-Handler, Chat-Antworten, Formular-Analyse, Dokument-Klassifikation on request

Ideal für

Periodische AI-Jobs

Nightly Summaries, tägliche Report-Generierung, Batch-Klassifikationen per Cron

Bedingt geeignet

Streaming-Responses

SSE/Streaming bei Vercel Edge möglich, bei AWS Lambda nur mit Response-Streaming-Flag

Achtung

Lange AI-Chains

Multi-Step-Reasoning über >5 Minuten passt nicht in Standard-Serverless-Timeouts

Das entscheidende Argument: Claude-API-Calls dauern typischerweise 3–30 Sekunden. Serverless-Functions sind genau für diese kurzen, unregelmäßigen Workloads optimiert. Du brauchst keine Prozess-Verwaltung, kein Scaling-Konfiguration und keinen 24/7-Monitoring-Stack für eine Funktion, die 50-mal täglich läuft.

2. Vercel Edge Functions vs. AWS Lambda vs. Cloudflare Workers — wann was

Die drei Hauptplattformen unterscheiden sich nicht nur in Preis und Verfügbarkeit, sondern fundamental in ihrer Runtime-Architektur. Das hat direkte Auswirkungen auf KI-Workloads.

Kriterium	Vercel Edge Functions	AWS Lambda	Cloudflare Workers
Runtime	V8 Isolate (Edge)	Node.js / Python / Container	V8 Isolate
Max. Timeout	30s (Hobby) / 300s (Pro)	15 Minuten	30s (Standard) / unbegrenzt (Durable Objects)
Max. Memory	128 MB (Edge) / 3 GB (Serverless)	128 MB – 10 GB	128 MB (Standard)
Cold Start	<50 ms (V8 Isolate)	200 ms – 2s (Node.js)	<5 ms (V8 Isolate)
KI-Streaming	Native SSE	Response Streaming	ReadableStream
npm Packages	Edge-kompatibel (kein Node-Core)	Voll kompatibel	Nur Web-APIs (kein Node-Core)
Free Tier	100k Req/Mo	1M Req/Mo	100k Req/Tag
Best für KI	Frontend-nahe Streaming-APIs	Komplexe Multi-Step-Chains, Cron	Ultra-Low-Latency, globale Distribution

Entscheidungshilfe: Neue Next.js-App mit KI-Chat? → Vercel API Routes. Nightly-Batch-Analyse von 500 Dokumenten? → AWS Lambda mit 15-Minuten-Timeout. Globale Echtzeit-Moderation mit <50 ms Latenz? → Cloudflare Workers. Lange Reasoning-Chains (>5 Min.)? → Keines davon — nimm einen VPS.

3. Konkrete Implementierungen

3a) Vercel API Route mit AI-Streaming (SSE)

Vercel Edge Runtime unterstützt Server-Sent Events nativ über ReadableStream. So baust du einen Streaming-Endpoint, der Claude-Tokens direkt an den Browser weiterleitet — ohne Buffer, ohne Delay.

// app/api/chat/route.ts — Vercel Edge Runtime
import Anthropic from '@anthropic-ai/sdk';

export const runtime = 'edge';

export async function POST(req: Request) {
  const { message } = await req.json();

  const client = new Anthropic({
    apiKey: process.env.ANTHROPIC_API_KEY,
  });

  // ReadableStream als SSE-Kanal
  const stream = new ReadableStream({
    async start(controller) {
      const encoder = new TextEncoder();

      const claudeStream = client.messages.stream({
        model: 'claude-opus-4-5',
        max_tokens: 1024,
        messages: [{ role: 'user', content: message }],
      });

      for await (const chunk of claudeStream) {
        if (chunk.type === 'content_block_delta' &&
            chunk.delta.type === 'text_delta') {
          // SSE-Format: "data: TOKEN\n\n"
          const sseData = `data: ${JSON.stringify({ text: chunk.delta.text })}\n\n`;
          controller.enqueue(encoder.encode(sseData));
        }
      }

      // Stream-Ende signalisieren
      controller.enqueue(encoder.encode('data: [DONE]\n\n'));
      controller.close();
    },
  });

  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive',
    },
  });
}

Auf der Client-Seite genügt ein einfaches EventSource-Setup oder fetch mit ReadableStream-Reader. Der entscheidende Vorteil: Der Nutzer sieht Tokens sofort, die wahrgenommene Latenz sinkt dramatisch — auch wenn der vollständige Response 8 Sekunden dauert.

# vercel.json — Edge Function Konfiguration { "functions": { "app/api/chat/route.ts": { "maxDuration": 60 } } }

Edge Runtime Einschränkung: Das @anthropic-ai/sdk nutzt intern node-fetch-Kompatibilitäts-Shims. Stelle sicher, dass du runtime = 'edge' nur verwendest wenn du das SDK in Version ≥ 0.26 einsetzt — ältere Versionen verwenden Node.js-spezifische APIs die im Edge-Kontext nicht verfügbar sind.

3b) AWS Lambda für periodische AI-Tasks (EventBridge Cron)

AWS Lambda ist die erste Wahl wenn du regelmäßige Batch-Verarbeitung mit KI brauchst: nightly Summaries, tägliche Kategorisierung neuer Einträge, wöchentliche Report-Generierung. EventBridge Scheduler ersetzt Lambda Scheduled Events mit präziserer Cron-Syntax.

# serverless.yml (Serverless Framework)
service: ai-nightly-summary

provider:
  name: aws
  runtime: nodejs20.x
  region: eu-central-1
  timeout: 300
  memorySize: 512
  environment:
    ANTHROPIC_API_KEY: ${ssm:/ai-summary/anthropic-key}
    DATABASE_URL: ${ssm:/ai-summary/db-url}

functions:
  nightlySummary:
    handler: src/handlers/nightly-summary.handler
    events:
      # Jeden Tag um 23:30 UTC ausführen
      - schedule: cron(30 23 * * ? *)

// src/handlers/nightly-summary.ts
import Anthropic from '@anthropic-ai/sdk';
import { fetchTodayEvents } from '../db/events';
import { sendSlackNotification } from '../notifications/slack';

export async function handler() {
  const client = new Anthropic();

  // 1. Daten aus DB holen
  const events = await fetchTodayEvents();
  if (events.length === 0) return { statusCode: 200, body: 'No events today' };

  // 2. Claude fasst zusammen
  const response = await client.messages.create({
    model: 'claude-haiku-4-5',  // Haiku für Batch-Tasks: günstiger
    max_tokens: 600,
    messages: [{
      role: 'user',
      content: `Fasse die folgenden ${events.length} Events in 5 Bullet Points zusammen. Nur das Wichtigste.\n\n${JSON.stringify(events, null, 2)}`
    }]
  });

  const summary = response.content[0].type === 'text'
    ? response.content[0].text : '';

  // 3. Ergebnis weiterleiten
  await sendSlackNotification({ text: `*Daily Summary:*\n${summary}` });

  return { statusCode: 200, body: 'Summary sent' };
}

Haiku statt Opus für Batch-Tasks: Für strukturierte Zusammenfassungen und Klassifikations-Tasks liefert claude-haiku-4-5 95 % der Qualität von Opus — zu einem Bruchteil der Kosten. Lambda-Cron-Jobs sind prädestiniert für dieses Modell.

3c) Webhook-Handler der Claude aufruft

Webhook-Handler sind der häufigste KI-Serverless-Use-Case: Stripe zahlt, Jira-Ticket wird erstellt, GitHub-PR wird geöffnet — und sofort läuft eine KI-Analyse. Das folgende Beispiel verarbeitet eingehende Support-E-Mails via Webhook und klassifiziert sie automatisch.

// api/webhook/support.ts (Vercel oder Next.js API Route)
import Anthropic from '@anthropic-ai/sdk';
import { createHmac } from 'crypto';

const client = new Anthropic();  // Singleton außerhalb Handler = warmup benefit

export async function POST(req: Request) {
  // 1. Webhook-Signatur validieren (IMMER!)
  const signature = req.headers.get('x-webhook-signature');
  const body = await req.text();
  const expected = createHmac('sha256', process.env.WEBHOOK_SECRET!)
    .update(body).digest('hex');
  if (signature !== `sha256=${expected}`) {
    return new Response('Unauthorized', { status: 401 });
  }

  const { subject, body: emailBody, from } = JSON.parse(body);

  // 2. Claude klassifiziert + bewertet Dringlichkeit
  const classification = await client.messages.create({
    model: 'claude-haiku-4-5',
    max_tokens: 200,
    messages: [{
      role: 'user',
      content: `Klassifiziere diese Support-Anfrage als JSON:
{"category": "billing|technical|general", "priority": "urgent|normal|low", "summary": "max 20 Wörter"}

Betreff: ${subject}
Text: ${emailBody.slice(0, 500)}`
    }]
  });

  const result = JSON.parse(
    classification.content[0].type === 'text' ? classification.content[0].text : '{}'
  );

  // 3. In DB schreiben, ggf. eskalieren
  await upsertTicket({ from, subject, ...result });
  if (result.priority === 'urgent') await alertOnCall(result.summary);

  return new Response('OK', { status: 200 });
}

Best Practice — Sofort 200 antworten: Bei langsamen Claude-Calls (>5s) besteht die Gefahr, dass der Webhook-Sender einen Timeout annimmt und nochmals sendet. Lösung: Sofort HTTP 200 zurückgeben und den Claude-Call in einer Queue (SQS, Upstash) nachlagern.

4. Cold Start Problem: So minimierst du Startup-Latenz

Cold Starts sind bei AI-Serverless-Funktionen besonders schmerzhaft: Nicht nur die Function muss booten — auch der HTTP-Client, die Anthropic-SDK-Instanz und ggf. Datenbankverbindungen müssen initialisiert werden. Hier sind die effektivsten Gegenmaßnahmen:

Strategie 1: Singleton außerhalb des Handlers

Der Anthropic-Client und Datenbankverbindungen sollten als Modul-Level-Konstanten deklariert werden. Bei Warm-Invocations wird der Modul-Scope wiederverwendet — keine Re-Initialisierung.

// ❌ Falsch: Client wird bei jedem Call neu erstellt
export async function handler(event) {
  const client = new Anthropic();  // Bei jedem Call!
  // ...
}

// ✅ Richtig: Singleton auf Modul-Ebene
const client = new Anthropic();  // Einmal beim Container-Start
export async function handler(event) {
  // client direkt nutzen
}

Strategie 2: Dependencies minimieren

Jedes zusätzliche npm-Package erhöht die Bundle-Größe und damit Cold-Start-Zeit. Nutze Tree-Shaking (esbuild / webpack) und importiere nur was gebraucht wird.

# esbuild Bundle-Analyse — was zieht alles rein?
npx esbuild src/handler.ts --bundle --analyze --platform=node > /dev/null

# Ziel: unter 2 MB für Lambda-Cold-Start unter 300 ms
# @anthropic-ai/sdk allein: ~180 KB (minified)

✓ Provisioned Concurrency (AWS Lambda): Hält X Instanzen permanent warm — kostet ca. €5–15/Mo pro Instanz, eliminiert Cold Starts für kritische Endpoints
✓ Warmup-Pings: Cron-Job pingt die Function alle 5 Minuten — hält sie warm, quasi kostenlos im Free Tier
✓ V8 Isolates bevorzugen: Vercel Edge und Cloudflare Workers starten in <5 ms — kein Cold-Start-Problem bei KI-Responses, die ohnehin 3–20s dauern
✓ Lazy Imports: Schwere Libraries (pdf-parse, sharp) erst beim ersten Aufruf laden der sie wirklich braucht
✗ Vermeide: SDK-Versionen mit nativen Node.js-Addons (bcrypt, sqlite3) — diese können nicht lazy geladen werden und verlängern Cold Starts massiv

5. Kostenvergleich: Serverless + KI-API vs. VPS

Die häufige Fehlannahme: "Serverless ist immer günstiger". Das stimmt bei niedrigem bis mittlerem Traffic — kippt aber ab einem bestimmten Volumen. Für KI-Workloads ist der Claude-API-Call fast immer der dominante Kostenfaktor, nicht die Infrastruktur.

Szenario	Serverless (Vercel Pro)	VPS (2 vCPU, 4 GB)	Gewinner
500 Requests/Tag	~€0 (Free Tier)	~€8/Mo (immer an)	Serverless
10.000 Requests/Tag	~€20–40/Mo	~€8/Mo	VPS ab ~5k
50.000 Requests/Tag	~€150–200/Mo	€25/Mo (2x VPS)	VPS klar
Claude API (Haiku)	~€0.0004 pro Request (500 Tokens in/out) — unabhängig von Infra		Gleich
Claude API (Opus)	~€0.015 pro Request (500 Tokens) — 37x teurer als Haiku		Gleich

Fazit Kosten: Bei <5.000 täglichen KI-Requests ist Serverless günstiger oder gleichwertig. Darüber wird ein kleiner VPS mit einem einfachen Node.js-Prozess fast immer billiger. Der Claude-API-Cost ist der eigentliche Hebel: Haiku statt Opus spart 97 % der API-Kosten bei vielen Use Cases.

Hybrides Modell: Das Beste beider Welten

Viele Production-Setups kombinieren: Vercel Edge für Frontend-nahe Streaming-Endpoints (geringe Latenz, automatisches CDN), AWS Lambda für schwere Batch-Jobs und Cron, VPS für dauerhaft laufende Prozesse (WebSocket-Server, Queue-Worker). Serverless wird dabei nicht ersetzt — sondern dort eingesetzt wo es wirklich passt.

6. Grenzen von Serverless: Was nicht funktioniert

Serverless ist kein Allheilmittel. Für KI-Workloads gibt es klare Grenzen, die man kennen muss bevor man sich in eine Architektur einbaut die später schmerzhaft rückgebaut werden muss.

Max. Execution Time

Vercel Hobby: 10s / Pro: 300s | AWS Lambda: 15 Min. | Cloudflare Workers: 30s
Agentic AI-Chains mit mehreren Claude-Calls, Tool-Use oder Reflection-Loops überschreiten leicht 5–10 Minuten. Das passt nicht in Serverless ohne Workarounds wie Step Functions (AWS) oder Durable Objects (Cloudflare).

Memory-Limits

Vercel Edge: 128 MB | Cloudflare Workers: 128 MB
Large Language Models lokal ausführen? Vektor-Embeddings für 100.000 Dokumente im Memory halten? Schleifen über große Dateimengen? Serverless scheidet hier aus. AWS Lambda mit bis zu 10 GB ist die Ausnahme — aber teuer.

Zustandsbehaftete Prozesse

Serverless Functions sind stateless. Kein In-Memory-State zwischen Requests. Jede laufende Konversation, jeder Workflow-State muss in einer externen DB (Redis, Supabase, DynamoDB) persistiert werden. Das fügt Latenz hinzu und macht Architekturen komplexer.

WebSocket / Persistente Verbindungen

Realtime-Chat mit persistenter WebSocket-Verbindung pro Nutzer ist mit Standard-Serverless nicht möglich. Cloudflare Durable Objects oder dedizierte WebSocket-Server (Soketi, Ably) sind hier die richtige Wahl.

✓ Geeignet: Einzelne Claude-Calls <30s, Webhook-Handler, Cron-Batch-Jobs, Streaming-Chat-Endpoints
✓ Geeignet: Functions die selten laufen (<10.000x/Tag) — Kosten-Vorteil klar
✗ Ungeeignet: Agentic Loops >5 Minuten, Multi-Step-Reasoning mit 10+ Tools
✗ Ungeeignet: Workloads die großen In-Memory-State brauchen (>128 MB)
✗ Ungeeignet: >50.000 Requests/Tag bei einfachen Tasks — VPS billiger
✗ Ungeeignet: Persistent WebSocket-Verbindungen, Session-State ohne externe DB

Fazit: Serverless ist ein Werkzeug, kein Standard

Serverless Functions und KI-APIs sind ein starkes Paar — für die richtigen Use Cases. Event-driven Tasks bis 5 Minuten Laufzeit, Webhook-Handler, Streaming-Endpoints, gelegentliche Batch-Jobs: hier glänzt Serverless durch Einfachheit, automatisches Scaling und geringe Kosten bei niedrigem Traffic.

Die kluge Entscheidung ist nicht "alles Serverless" oder "alles VPS", sondern: Request-Volume, Laufzeit und Zustandsbedarf bestimmen die Architektur. Bei <5.000 täglichen Claude-Calls ist Serverless fast immer die schnellere, günstigere Option um in Produktion zu kommen.

Zusammenfassung: Vercel Edge für Frontend-nahe Streaming-Endpoints. AWS Lambda für Cron-Batch-Jobs bis 15 Minuten. Cloudflare Workers für ultraschnelle globale Distribution. VPS sobald tägliche Request-Zahlen fünfstellig werden oder agentic Loops >5 Minuten laufen.

Serverless AI-Workflows mit Claude Code aufbauen

Von der ersten Vercel API Route bis zur Lambda-Produktionsinfrastruktur — Claude Code beschleunigt jeden Schritt. Keine Kreditkarte nötig.

14 Tage kostenlos testen →