Cloudflare Workers vs AWS Lambda Vergleich

Compute, das mit V8-Isolaten global am Edge läuft — ohne VM-Kaltstart

VS
AWS Lambda

Serverless Compute, das auf Firecracker-microVMs läuft und tief in das AWS-Ökosystem integriert ist

17 Min. LesezeitBackend

Schnelles Fazit

Es gibt keinen klaren Gewinner: Für kurze, latenzkritische, global verteilte Workloads (Auth, Routing, Personalisierung, API-Gateway, Webhook) ist Cloudflare Workers sowohl günstiger als auch mit weniger Kaltstart-Reibung verbunden. Bei lang laufenden, speicherintensiven oder VPC-internen AWS-Ressourcen-abhängigen Aufgaben liegt Lambda vorn: Die Obergrenzen sind großzügiger, der Zugriff auf private Netzwerke ist GA — bei Workers noch Beta. Das häufigste Produktionsmuster ist hybrid: Workers als dünne Schicht am Edge, Lambda für die schwere Arbeit im Hintergrund.

Cloudflare WorkersAWS Lambda
Vollständiges Fazit lesen

Punktevergleich

Diagramm wird geladen...

Detaillierte Bewertung

Detaillierte Bewertung: Cloudflare Workers und AWS Lambda — Bewertungen pro Kategorie auf einer Skala von 1 bis 10
KategorieCloudflare WorkersAWS Lambda
Performance
8/10
7/10
Erlernbarkeit
7/10
6/10
Ökosystem
6/10
9/10
Community
6/10
8/10
Arbeitsmarkt
6/10
8/10
Zukunftssicherheit
9/10
8/10

Vor- und Nachteile

Cloudflare Workers

Vorteile

  • V8-Isolate starten laut Cloudflare rund 100-mal schneller als ein Node-Prozess
  • Preismodell nach CPU-Time; Wartezeit auf I/O ist kostenlos
  • Datenebene wie KV, D1, R2, Durable Objects und Hyperdrive auf derselben Plattform
  • Leichtgewichtige lokale Entwicklung mit Wrangler und globales Deployment mit einem Befehl
  • 100.000 Requests/Tag im Free-Plan; im Paid-Plan 5 $ Grundgebühr + großzügiges enthaltenes Kontingent
  • workerd-Runtime ist unter der Apache-2.0-Lizenz Open Source
  • Verbindungspool zu bestehenden Postgres-/MySQL-Datenbanken (einschließlich AWS RDS) über Hyperdrive
  • Node.js-API-Kompatibilitäten wie node:fs erleichtern die Portierung bestehender Bibliotheken

Nachteile

  • CPU-Time standardmäßig 30 Sekunden, bei HTTP-Requests Obergrenze 5 Minuten (Paid) — für lange synchrone Aufgaben ungeeignet
  • Speicher fest bei 128 MB, nicht erhöhbar
  • Selbst bei Cron Triggern und Queue Consumern ist ein einzelner Aufruf auf 15 Minuten begrenzt (bei Cron nur bei Intervallen ab 1 Stunde; darunter 30 s) — stundenlange Batch-Jobs sind nicht nativ möglich
  • Das V8-Isolate-Modell unterstützt keine nativen Node.js-Addons
  • Im Free-Plan ist die CPU-Time auf 10 ms begrenzt; für Produktionstraffic ist der Paid-Plan erforderlich
  • Es fehlt die Tiefe der direkten Trigger-/Event-Source-Mapping-Integration von AWS-Diensten, das Ökosystem ist enger

Am besten geeignet für

Kurze, latenzkritische, global verteilte Request-Verarbeitung wie Authentifizierung, Routing, PersonalisierungDünne Schicht vor API-Gateway oder WebhookA/B-Tests und Response-Manipulation am EdgeLeichte dynamische Logik direkt neben dem CDNLatenzarme Antworten für geografisch verteilte Nutzergruppen

AWS Lambda

Vorteile

  • Flexible Speicherkonfiguration von 128 MB bis 10.240 MB
  • Maximale Laufzeit 15 Minuten; mit Managed Instances Übergang zu länger laufenden Workloads möglich
  • VPC-Zugriff ermöglicht direkte Verbindung zu privaten Netzwerkressourcen wie RDS, ElastiCache
  • Native Integration mit AWS-Diensten: S3, DynamoDB, SQS, Kinesis, EventBridge, API Gateway und Cognito können die Funktion direkt auslösen
  • Tiefe Observability mit CloudWatch + X-Ray
  • Breite Runtime-Unterstützung: Node.js, Python, Java, Go, .NET, Ruby, Custom Runtime
  • Free Tier: 1 Mio. Requests + 400.000 GB-Sekunden/Monat

Nachteile

  • Kaltstart der Firecracker-microVM ist langsamer als bei V8-Isolaten (wird mit Hyperplane-ENI in der VPC reduziert, aber nicht eliminiert)
  • Preismodell nach GB-Sekunden; Abrechnung über Speicher × Laufzeit
  • Eine an eine VPC gebundene Funktion ist standardmäßig vom Internet abgeschnitten — NAT Gateway/VPC-Endpoint erforderlich
  • Keine globale PoP-Verbreitung; läuft regionsbasiert, kein automatisches Routing zum nächstgelegenen Edge
  • Lokale Entwicklung mit SAM/CDK ist nicht so leichtgewichtig wie mit Wrangler
  • Die breite Servicefläche für Integrationen birgt Komplexitäts- und Vendor-Lock-in-Risiko

Am besten geeignet für

Workloads, die von privaten AWS-Ressourcen innerhalb einer VPC wie RDS/ElastiCache abhängenLang laufende Datenverarbeitung, ETL, Batch-/Queue-Consumer-AufgabenBild-/Videoverarbeitung oder ML-Inferenz mit hohem SpeicherbedarfEvent-getriebene Orchestrierung in AWS-nativer Architektur (S3, DynamoDB, Step Functions)Unternehmensteams mit bereits tiefer AWS-Investition

Code-Vergleich

Cloudflare Workers
// Cloudflare Workers - API, die über Hyperdrive mit Postgres verbunden ist
import { Hono } from "hono";
import postgres from "postgres";

interface Env {
  HYPERDRIVE: Hyperdrive;
}

const app = new Hono<{ Bindings: Env }>();

app.get("/api/users/:id", async (c) => {
  // Bei jedem Request einen neuen Client zu öffnen ist schnell — Hyperdrive
  // hält den Connection Pool bereits auf Plattformseite.
  const sql = postgres(c.env.HYPERDRIVE.connectionString, {
    max: 5,
    fetch_types: false,
  });

  // Hyperdrive räumt die Verbindung nach Abschluss des Requests selbst auf; sql.end() muss nicht aufgerufen werden.
  const id = c.req.param("id");
  const rows = await sql`
    SELECT id, name, plan FROM users WHERE id = ${id} LIMIT 1
  `;

  if (rows.length === 0) {
    return c.json({ error: "not_found" }, 404);
  }

  return c.json(rows[0]);
});

export default app;

/*
wrangler.jsonc
{
  "name": "edge-api",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-01",
  "hyperdrive": [
    { "binding": "HYPERDRIVE", "id": "<hyperdrive-config-id>" }
  ]
}
*/
AWS Lambda
// AWS Lambda (Node.js) - Handler, der mit RDS Postgres in der VPC verbunden ist
import { Client } from "pg";

let client; // bleibt bei Container-Wiederverwendung (Warm Start) erhalten

export const handler = async (event) => {
  const id = event.pathParameters?.id;

  if (!client) {
    client = new Client({
      host: process.env.DB_HOST, // privater RDS-Endpoint (innerhalb der VPC)
      port: 5432,
      database: process.env.DB_NAME,
      user: process.env.DB_USER,
      password: process.env.DB_PASSWORD,
      ssl: { rejectUnauthorized: true },
    });
    await client.connect();
  }

  try {
    const result = await client.query(
      "SELECT id, name, plan FROM users WHERE id = $1 LIMIT 1",
      [id]
    );

    if (result.rows.length === 0) {
      return { statusCode: 404, body: JSON.stringify({ error: "not_found" }) };
    }

    return { statusCode: 200, body: JSON.stringify(result.rows[0]) };
  } catch (err) {
    console.error(err);
    return { statusCode: 500, body: JSON.stringify({ error: "internal" }) };
  }
};

/*
template.yaml (AWS SAM) — VPC + Speicher + Timeout
Resources:
  UsersFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      MemorySize: 512
      Timeout: 15 # Sekunden (Obergrenze 900 = 15 Minuten)
      VpcConfig:
        SecurityGroupIds: [sg-xxxxxxxx]
        SubnetIds: [subnet-xxxxxxxx, subnet-yyyyyyyy]
      Policies:
        - VPCAccessPolicy: {}
*/

Fazit

Es gibt keinen klaren Gewinner: Für kurze, latenzkritische, global verteilte Workloads (Auth, Routing, Personalisierung, API-Gateway, Webhook) ist Cloudflare Workers sowohl günstiger als auch mit weniger Kaltstart-Reibung verbunden. Bei lang laufenden, speicherintensiven oder VPC-internen AWS-Ressourcen-abhängigen Aufgaben liegt Lambda vorn: Die Obergrenzen sind großzügiger, der Zugriff auf private Netzwerke ist GA — bei Workers noch Beta. Das häufigste Produktionsmuster ist hybrid: Workers als dünne Schicht am Edge, Lambda für die schwere Arbeit im Hintergrund.

Kostenlose Beratung erhalten
FAQ

Häufig gestellte Fragen

Das hängt vom Workload ab und muss individuell berechnet werden. Der Workers-Paid-Plan enthält für 5 $/Monat Grundgebühr 10 Millionen Requests und 30 Millionen CPU-Millisekunden; bei Überschreitung kommen 0,30 $/Million Requests und 0,02 $/Million CPU-ms hinzu — Wartezeit auf I/O ist kostenlos. Lambda berechnet dagegen nach Requests plus GB-Sekunden (Speicher × Laufzeit); die kostenlose Stufe umfasst 1 Million Requests und 400.000 GB-Sekunden pro Monat. Bei kurzen, I/O-lastigen Aufgaben kann das CPU-Time-Modell von Workers günstiger ausfallen; bei langen, CPU-intensiven Aufgaben hängt das GB-Sekunden-Modell von Lambda stark vom jeweiligen Workload ab.

Verwandte Blogartikel

Alle Artikel ansehen

Verwandte Projekte

Alle Projekte ansehen
Alle Vergleiche