Cloudflare Workers vs AWS Lambda Comparaison

Compute s'exécutant en périphérie globale via des isolates V8, sans démarrage à froid de VM

VS
AWS Lambda

Compute serverless s'exécutant sur une microVM Firecracker, profondément intégré à l'écosystème AWS

17 min de lectureBackend

Verdict rapide

Il n'y a pas de vainqueur absolu : pour les charges de travail courtes et sensibles à la latence traitant des requêtes globales (authentification, routage, personnalisation, API gateway, webhook), Cloudflare Workers est à la fois moins cher et offre moins de friction au démarrage à froid. Pour les tâches longues, gourmandes en mémoire ou dépendantes de ressources AWS internes au VPC, Lambda a l'avantage : les plafonds sont plus larges et l'accès réseau privé est GA, alors que chez Workers il est encore en bêta. Le schéma de production le plus courant est hybride : Workers en couche fine à la périphérie, Lambda pour le travail lourd en arrière-plan.

Cloudflare WorkersAWS Lambda
Lire le verdict complet

Comparaison des scores

Chargement du graphique...

Notation détaillée

Notation détaillée: Cloudflare Workers et AWS Lambda — notes sur 10, catégorie par catégorie
CatégorieCloudflare WorkersAWS Lambda
Performance
8/10
7/10
Facilité d'apprentissage
7/10
6/10
Écosystème
6/10
9/10
Communauté
6/10
8/10
Marché de l'emploi
6/10
8/10
Pérennité
9/10
8/10

Avantages & Inconvénients

Cloudflare Workers

Avantages

  • L'isolate V8 démarre, selon les termes de Cloudflare, environ 100 fois plus vite qu'un processus Node
  • Tarification basée sur le CPU-time ; le temps d'attente d'E/S est gratuit
  • Couche de données intégrée à la même plateforme : KV, D1, R2, Durable Objects, Hyperdrive
  • Développement local léger et déploiement global en une commande avec Wrangler
  • 100 000 requêtes/jour sur le plan gratuit ; base à 5 $ + large quota inclus sur le plan payant
  • Le runtime workerd est open source sous licence Apache-2.0
  • Pool de connexions vers Postgres/MySQL existants (y compris AWS RDS) via Hyperdrive
  • Les compatibilités d'API Node.js comme node:fs facilitent le portage des bibliothèques existantes

Inconvénients

  • CPU-time par défaut de 30 s, plafond de 5 min pour une requête HTTP (payant) — inadapté aux tâches synchrones longues
  • Mémoire fixe à 128 Mo, non extensible
  • Même avec les Cron Triggers et les Queue Consumers, une invocation est plafonnée à 15 min (pour Cron uniquement avec un intervalle d'au moins 1 heure ; 30 s en dessous) — les tâches par lots de plusieurs heures ne sont pas natives
  • Le modèle d'isolate V8 ne prend pas en charge les addons Node.js natifs
  • Sur le plan gratuit, le CPU-time est limité à 10 ms ; le plan payant est indispensable pour un trafic de production
  • Pas de profondeur équivalente de déclencheurs directs/event source mapping des services AWS, écosystème plus restreint

Idéal pour

Traitement de requêtes globales courtes et sensibles à la latence : authentification, routage, personnalisationCouche fine devant une API gateway ou un webhookTests A/B et manipulation de réponse en périphérieLogique dynamique légère adjacente au CDNRéponse à faible latence pour une base d'utilisateurs géographiquement dispersée

AWS Lambda

Avantages

  • Configuration mémoire flexible de 128 Mo à 10 240 Mo
  • Durée d'exécution maximale de 15 min ; possibilité de passer à des charges plus longues avec Managed Instances
  • Accès VPC permettant une connexion directe aux ressources réseau privées comme RDS, ElastiCache
  • Intégration native aux services AWS : S3, DynamoDB, SQS, Kinesis, EventBridge, API Gateway, Cognito peuvent déclencher directement une fonction
  • Observabilité approfondie avec CloudWatch + X-Ray
  • Large support de runtimes : Node.js, Python, Java, Go, .NET, Ruby, runtime personnalisé
  • Palier gratuit : 1 million de requêtes + 400 000 Go-secondes/mois

Inconvénients

  • Le démarrage à froid de la microVM Firecracker est plus lent que celui de l'isolate V8 (réduit par Hyperplane ENI en VPC, mais pas éliminé)
  • Tarification basée sur les Go-secondes ; facturée selon mémoire × durée
  • Une fonction connectée à un VPC est fermée à Internet par défaut — NAT Gateway ou point de terminaison VPC indispensable
  • Pas de présence de PoP globale ; fonctionne par région, sans routage automatique vers l'edge le plus proche
  • Le développement local avec SAM/CDK n'est pas aussi léger que Wrangler
  • La large surface d'intégration de services comporte un risque de complexité et de vendor lock-in

Idéal pour

Charges de travail dépendant de ressources AWS privées internes au VPC comme RDS/ElastiCacheTraitement de données long, ETL, tâches consommatrices de lots/files d'attenteTraitement d'image/vidéo ou inférence ML nécessitant beaucoup de mémoireOrchestration événementielle dans une architecture AWS native (S3, DynamoDB, Step Functions)Équipes d'entreprise déjà fortement investies dans AWS

Comparaison de code

Cloudflare Workers
// Cloudflare Workers - API connectée à Postgres via Hyperdrive
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) => {
  // Ouvrir un nouveau client à chaque requête est rapide — Hyperdrive
  // maintient déjà le pool de connexions côté plateforme.
  const sql = postgres(c.env.HYPERDRIVE.connectionString, {
    max: 5,
    fetch_types: false,
  });

  // Hyperdrive nettoie lui-même la connexion à la fin de la requête ; pas besoin d'appeler sql.end().
  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 connecté à RDS Postgres dans un VPC
import { Client } from "pg";

let client; // conservé lors de la réutilisation du conteneur (warm start)

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

  if (!client) {
    client = new Client({
      host: process.env.DB_HOST, // point de terminaison privé RDS (dans le 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 + mémoire + timeout
Resources:
  UsersFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      MemorySize: 512
      Timeout: 15 # secondes (plafond 900 = 15 min)
      VpcConfig:
        SecurityGroupIds: [sg-xxxxxxxx]
        SubnetIds: [subnet-xxxxxxxx, subnet-yyyyyyyy]
      Policies:
        - VPCAccessPolicy: {}
*/

Conclusion

Il n'y a pas de vainqueur absolu : pour les charges de travail courtes et sensibles à la latence traitant des requêtes globales (authentification, routage, personnalisation, API gateway, webhook), Cloudflare Workers est à la fois moins cher et offre moins de friction au démarrage à froid. Pour les tâches longues, gourmandes en mémoire ou dépendantes de ressources AWS internes au VPC, Lambda a l'avantage : les plafonds sont plus larges et l'accès réseau privé est GA, alors que chez Workers il est encore en bêta. Le schéma de production le plus courant est hybride : Workers en couche fine à la périphérie, Lambda pour le travail lourd en arrière-plan.

Obtenir une consultation gratuite
FAQ

Questions fréquentes

Cela varie et doit être calculé selon la charge de travail. Le plan payant de Workers coûte 5 $/mois de base, incluant 10 millions de requêtes et 30 millions de CPU-ms, avec un dépassement facturé 0,30 $/million de requêtes + 0,02 $/million de CPU-ms ; le temps d'attente d'E/S est gratuit. Lambda facture selon requêtes + Go-secondes (mémoire × durée), le palier gratuit incluant 1 million de requêtes + 400 000 Go-secondes/mois. Pour des tâches courtes et dominées par les E/S, le modèle CPU-time de Workers peut devenir moins cher ; pour des tâches longues et intensives en CPU, le modèle Go-secondes de Lambda varie selon la charge de travail.

Articles de blog associés

Voir tous les articles

Projets associés

Voir tous les projets
Toutes les comparaisons