Comparatif · SaaS & dev
Workers, Functions et Lambda, d’après les docs
Docs Workers, Vercel Functions et Lambda lues le 2026-10-18. Aucun appel d’API n’a été exécuté, et aucun prix n’est recopié.
Cloudflare Workers, Vercel Functions et Lambda ont été lus ensemble le 2026-10-18, sans les ranger. Cloudflare décrit des isolats V8 sur son réseau. Vercel décrit des fonctions de requête, avec Fluid compute activé par défaut pour les nouveaux projets. Lambda décrit un environnement d’exécution par invocation, dans une région AWS, avec un rôle IAM. Aucun test n’a été exécuté pour écrire cette page, et aucun prix n’est recopié. Aucun exemple d’API n’a été appelé.
Cloudflare Workers
Pages lues : How Workers works et Limits. Le guide de démarrage CLI, CLI, crée un Worker JavaScript avec Wrangler.
Le runtime utilise V8. Une fonction tourne dans un isolat, pas dans une machine virtuelle créée pour elle. La page dit que ce modèle élimine les démarrages à froid du modèle à machine virtuelle, et qu’un isolat démarre bien plus vite qu’un processus Node sur conteneur. C’est une affirmation de Cloudflare. Elle n’a pas été rejouée ici.
Un isolat peut être évincé : machine chargée, script jugé suspect, ou limite de ressources. La page déconseille donc un état mutable dans la portée globale, sauf si vous avez prévu cette éviction. Deux requêtes ne sont pas garanties d’atterrir sur la même instance. Plusieurs requêtes peuvent partager une boucle d’événements. Attendre un fetch peut laisser passer une autre requête. Ce n’est pas un processus qui vous appartient entre deux appels.
La durée murale d’un Worker HTTP n’a pas de plafond dur tant que le client reste connecté. Le plafond cité est le temps CPU. Sur le plan Free, 10 ms par requête HTTP. Sur le plan Paid, 5 minutes au maximum, 30 secondes par défaut. waitUntil() peut prolonger le travail jusqu’à 30 secondes après la réponse ou la déconnexion. La mémoire citée est de 128 Mo par isolat, pas par invocation. Le plan Free a aussi un plafond quotidien de 100 000 requêtes. Les tarifs de ces plans ne sont pas recopiés. Une page Python à part, non détaillée ici, documente Pyodide dans un isolat. Le guide de démarrage ouvert, lui, est en JavaScript.
Vercel Functions
Pages lues : Vercel Functions et Fluid compute. La page Fluid compute indique une mise à jour du 14 mai 2026.
Vercel présente ces fonctions comme des routes d’API, des webhooks, des réponses de modèle en flux, et des tours d’agent. Au déploiement, la plateforme place le trafic sur son CDN et peut épingler une fonction dans une région si la donnée doit rester proche. La page dit d’utiliser Vercel Workflows, ou eve, si un agent doit garder sa progression à travers une pause ou un déploiement. Une Function seule ne promet pas cet état.
Fluid compute est activé par défaut pour les nouveaux projets depuis le 23 avril 2025. La page le décrit comme plusieurs invocations dans une même instance, pour les runtimes Node.js et Python. Une erreur non gérée ne doit pas faire tomber les autres requêtes concurrentes de l’instance. waitUntil sert au travail après la réponse. Le basculement de zone de disponibilité, puis vers la région suivante si toute la région tombe, est documenté. Je n’ai pas trouvé, sur ces deux pages, un plafond de durée murale à recopier. Il reste sur les pages de limites de Vercel, à relire avant de s’y fier. Aucun montant du « lower costs » annoncé sur Fluid compute n’est recopié.
AWS Lambda
Pages lues : How Lambda works et Understanding the Lambda execution environment lifecycle.
Lambda invoque la fonction dans un environnement d’exécution qu’il gère. Vous indiquez la mémoire et le temps d’exécution maximal. L’environnement contient un runtime, ou le vôtre, et éventuellement des extensions. Chaque fonction a un rôle d’exécution IAM. Lambda l’assume à l’invocation. Le rôle créé depuis la console, d’après la page des concepts, permet d’écrire dans CloudWatch Logs. Une action de plus, par exemple lire une table DynamoDB, s’ajoute au rôle. Un déclencheur relie la fonction à une source d’événements. L’appel direct via la console, la CLI ou un SDK est aussi documenté.
Les fonctions standard vont jusqu’à 15 minutes. Les Durable Functions vont jusqu’à un an, avec persistance d’état entre les étapes, checkpoints, et des pauses qui ne consomment pas les ressources de la même façon. Ce n’est pas le même produit que la fonction courte, même si le cycle de vie de base est partagé.
Pour les fonctions par défaut, un environnement traite une requête à la fois. S’il est réutilisé, c’est après la fin de l’invocation, et Lambda ne garantit pas cette réutilisation. La page dit que les environnements sont arrêtés toutes les quelques heures, même si la fonction est appelée sans pause. Il ne faut pas y laisser l’état dont vous avez besoin. Les Lambda Managed Instances, page distincte citée mais non détaillée ici, acceptent des invocations concurrentes et tournent sur une infrastructure que le compte possède.
La phase Init est limitée à 10 secondes, sauf provisioned concurrency, SnapStart, ou Managed Instances. Un démarrage à froid télécharge le code, prépare l’environnement, puis lance l’initialisation hors handler. AWS écrit, à partir d’une analyse de charges en production, que ces démarrages concernent en général moins de 1 % des invocations, et durent de moins de 100 ms à plus d’une seconde. C’est leur chiffre, pas une mesure faite pour cette page. Après un échec d’invocation, le reset ne vide pas /tmp.
Côté à côte
| Point relu | Workers | Vercel Functions | Lambda |
|---|---|---|---|
| Où le code tourne | Réseau Cloudflare, isolat V8 | Plateforme Vercel, région épinglable | Région AWS, plusieurs zones de disponibilité |
| Concurrence dans une instance | Possible sur la boucle d’événements, sans affinité | Fluid compute : plusieurs invocations, Node.js et Python | Défaut : une requête à la fois ; Managed Instances : concurrent, page non détaillée |
| Durée | Pas de plafond murale HTTP si le client reste ; plafond CPU | Non chiffrée sur les deux pages ouvertes | 15 minutes en standard ; un an en Durable Functions |
| État entre deux appels | Isolat évincable, état global déconseillé | Workflows ou eve si la progression doit survivre | Environnement gelé puis jeté ; ne pas s’y fier |
| Identité | Non résumée sur les pages ouvertes | Compte et projet Vercel, non détaillés ici | Rôle IAM d’exécution, obligatoire |
| Déclencheur cité | Requête HTTP dans les pages lues ; cron cité dans les limites | Route, webhook, flux de modèle | Événement AWS, ou appel direct |
Le tableau ne dit pas laquelle répond le plus vite. Il reprend des phrases de docs, datées du 2026-10-18.
Cas où l’autre option reste préférable
Lambda reste préférable si le travail doit tenir jusqu’à 15 minutes de temps d’exécution, ou s’il s’agit d’un flux Durable Functions qui checkpoint et peut durer jusqu’à un an. Il reste préférable si l’événement naît dans le compte AWS : un objet S3, une table DynamoDB, une file. Le rôle IAM est alors le mécanisme que la doc décrit, pas un ajout. Workers et Vercel Functions ne remplacent pas ce rôle dans les pages lues.
Workers reste préférable si le handler est du JavaScript court, proche du réseau Cloudflare, et si le budget CPU documenté suffit. Le plan Free, à 10 ms de CPU par requête, reste un mauvais endroit pour parser une grosse charge ou faire un rendu lourd. La page des limites le sépare du plan Paid, dont le défaut est 30 secondes de CPU. Le tarif de ce plan n’est pas ici. Workers reste aussi préférable à une fonction qui compterait sur une variable globale : la doc dit que l’isolat peut disparaître.
Vercel Functions reste préférable si le code est déjà une route de l’application déployée sur Vercel, et si vous voulez l’intégration au framework plus Fluid compute, plutôt qu’un Worker Wrangler ou un rôle Lambda. Elle reste préférable pour une réponse de modèle en flux telle que la page Functions la montre. Elle cesse de l’être si l’agent doit survivre à une pause ou à un redéploiement : la même page renvoie vers Workflows ou eve.
Un processus que vous gardez allumé reste préférable si vous avez besoin d’une connexion longue que ces trois docs ne promettent pas entre deux requêtes. Je n’ai pas installé ce processus. Je note seulement que les trois pages déconseillent, chacune à sa façon, de traiter l’instance comme une machine à vous.
Ce qui n’a pas été fait
Aucun test n’a été exécuté. Aucune fonction n’a été déployée, aucun appel d’API n’a été lancé, aucun délai n’a été mesuré. Aucun prix n’est recopié. Les plafonds cités viennent des pages de limites et du cycle de vie Lambda, pas d’une facture.