En moins d'un an, AWS Lambda est passé d'un modèle d'exécution unique à une famille complète : Managed Instances fin 2025, MicroVMs en juin 2026 puis Web Functions en octobre, tandis que les fonctions historiques deviennent des Event Functions. Chaque forme répond à une question différente, et un mauvais choix se paie aussi bien sur la facture qu'en complexité d'exploitation. Découvrez comment choisir le bon modèle selon le déclencheur, la concurrence, la durée et le coût de vos charges.
AWS Lambda traite aujourd’hui plus de 15 000 milliards d’invocations par mois, et pendant plus de dix ans toutes ces invocations ont obéi au même contrat : un événement arrive, une fonction le traite dans un environnement isolé qui ne fait rien d’autre pendant ce temps, puis la facture retient la durée totale multipliée par la mémoire configurée. Ce contrat a fait le succès du serverless sur AWS ; il en a aussi dessiné les limites, puisque les applications web payaient leurs temps d’attente au prix du calcul et que les usages hors de ce cadre (sessions longues, code non fiable, trafic massif et régulier) partaient vers les conteneurs.
En dix mois, AWS a comblé ces trois angles morts. Lambda Managed Instances, présenté à re:Invent fin 2025, fait tourner des fonctions sur des instances EC2 gérées par Lambda. Lambda MicroVMs, lancé en juin 2026, fournit des machines virtuelles isolées dont l’application pilote le cycle de vie. Lambda Web Functions, lancé le 12 octobre 2026, exécute un serveur HTTP standard facturé au CPU actif. Les fonctions historiques prennent au passage le nom d’Event Functions.
Pour une équipe qui exploite déjà Lambda, la question devient concrète : faut-il migrer les API vers Web Functions, conserver les fonctions actuelles, ou réserver ces nouveautés à des cas précis ? La réponse dépend moins du prix que de la nature du travail à exécuter.
Un même socle, trois contrats d’exécution
Event Functions, Web Functions et MicroVMs reposent toutes sur Firecracker, la technologie de micro-VM open source qu’AWS a développée pour Lambda. Ce qui les distingue n’est donc pas l’isolation, mais le contrat passé avec votre code : ce qui déclenche le travail, le nombre de requêtes qu’un environnement traite en même temps, qui décide de la durée de vie de cet environnement et ce que la facture mesure.
| Critère | Event Functions | Web Functions | MicroVMs |
|---|---|---|---|
| Déclencheur | un événement (SQS, S3, EventBridge, flux, planification…) | une requête HTTPS | un appel run-microvm, puis les connexions des clients |
| Modèle de programmation | un handler (event, context) | un serveur HTTP qui écoute sur un port | une application quelconque, construite depuis un Dockerfile |
| Concurrence par environnement | une invocation | 64 par défaut, 128 au maximum | pilotée par l’application |
| Cycle de vie | géré par Lambda | géré par Lambda | piloté par l’application (lancement, suspension, reprise, arrêt) |
| Durée | 15 minutes par invocation | 15 minutes par requête (30 s par défaut) | sessions de plusieurs heures, suspension jusqu’à 8 h |
| Langages | Node.js, Python, Java, .NET, Ruby, runtimes personnalisés | Node.js 24 uniquement | tous, via l’image |
| Facturation | requêtes + durée totale × mémoire configurée | requêtes + CPU actif + mémoire consommée | vCPU + mémoire + snapshots |
| Retour à zéro | oui | oui, sans environnement minimum | suspension sans frais de calcul |
| Régions européennes | toutes, dont Paris | Irlande | Irlande, Francfort, Stockholm |
| Réseau entrant | API Gateway, Function URL, ALB | endpoint HTTPS intégré, HTTP/1.1 | endpoint HTTPS dédié, HTTP/2, gRPC, WebSocket |
Lambda Managed Instances n’apparaît pas dans ce tableau parce qu’il ne constitue pas une quatrième forme : c’est un mode d’hébergement des Event Functions, sur lequel nous revenons plus bas.
Event Functions : l’événement comme unité de travail
L’Event Function reste le modèle par défaut pour tout ce qui est asynchrone : consommer une file SQS, réagir au dépôt d’un fichier dans S3, traiter un flux Kinesis ou DynamoDB, exécuter une tâche planifiée. Son contrat d’une invocation par environnement est souvent présenté comme une contrainte, mais c’est aussi une garantie : aucune donnée ne circule entre deux traitements simultanés, une variable globale ne risque pas de mélanger les requêtes de deux utilisateurs, et les mécanismes de reprise sur erreur (tentatives, files de messages en échec) sont intégrés aux sources d’événements.
C’est également le seul modèle disponible pour une API écrite dans un autre langage que Node.js, et le seul présent dans la région de Paris. Une API Python, Java ou .NET continue donc de passer par API Gateway, une Function URL ou un ALB devant une Event Function.
Sa facturation mérite d’être bien comprise, parce qu’elle conditionne les comparaisons. Une Event Function est facturée à la durée totale de l’invocation multipliée par la mémoire configurée, et son CPU est proportionnel à cette mémoire : il faut configurer 1 769 Mo pour disposer de l’équivalent d’un vCPU. Une fonction à 512 Mo ne dispose donc que d’environ un tiers de vCPU.
Managed Instances : les Event Functions sur EC2
Managed Instances répond à une critique ancienne de Lambda : à fort volume et à charge stable, le modèle à la durée revient plus cher que des instances EC2. Avec ce mode, vos Event Functions s’exécutent sur des instances EC2 de votre compte, que Lambda provisionne, met à jour et répartit. Un environnement y traite plusieurs invocations simultanées, et la facture suit le tarif EC2 de l’instance (éligible aux Savings Plans et aux instances réservées) majoré de frais de gestion de 15 %.
La contrepartie est double. Lambda lance par défaut trois instances pour couvrir trois zones de disponibilité, et le service ne redescend jamais à zéro : vous payez les instances même sans trafic. L’isolation repose par ailleurs sur des conteneurs sur instances Nitro, et non sur Firecracker. Managed Instances s’adresse donc aux charges élevées et prévisibles, pour lesquelles les remises EC2 compensent le coût d’une capacité permanente.
Web Functions : la requête HTTP comme unité de travail
Une Web Function exécute votre application Node.js telle qu’elle tourne en local : un serveur Express, Fastify, Koa ou Next.js qui écoute sur le port fourni par Lambda, sans handler ni adaptateur. Chaque environnement de 2 Go et 2 vCPU traite plusieurs requêtes à la fois, et Lambda ajoute des environnements à mesure que le trafic augmente. Nous avons détaillé le déploiement, la sécurisation de l’endpoint et les commandes de canary dans notre insight Lambda Web Functions : un vrai serveur HTTP sur Lambda, facturé au CPU actif.
Les charges qui en tirent le meilleur parti partagent une caractéristique : elles passent l’essentiel de leur temps à attendre. C’est le cas du rendu côté serveur d’un site Next.js qui interroge une base et des API, des API REST ou GraphQL, des microservices qui appellent d’autres services, des webhooks et, surtout, des endpoints qui relaient en streaming la réponse d’un LLM.
Trois contraintes cadrent toutefois son usage :
- le code doit être sûr en concurrence : une fonction écrite pour le modèle à une invocation par environnement peut stocker l’état d’une requête dans une variable globale sans conséquence ; portée telle quelle sur une Web Function, elle risque de mélanger les données de deux utilisateurs. La migration d’une fonction existante impose une revue de ce point ;
- le démarrage à froid revient après chaque période creuse : Lambda conserve une marge de capacité tant que le trafic circule, mais il n’existe aucun réglage d’environnement minimum, et AWS ne publie aucune mesure de démarrage à froid ;
- le périmètre est encore restreint : Node.js 24 sur Arm64, cinq régions dont l’Irlande comme seule implantation européenne, et un endpoint créé public par défaut.
MicroVMs : la session isolée comme unité de travail
Les MicroVMs répondent à un besoin que ni les Event Functions ni les Web Functions ne couvrent : exécuter du code qui n’est pas le vôtre. Un assistant de programmation qui lance le code qu’il vient de générer, un notebook dans lequel un analyste exécute ses scripts, une plateforme d’intégration continue multi-clients ou un outil d’analyse de paquets suspects ont tous besoin d’un environnement isolé au niveau de la machine virtuelle, qui démarre vite et conserve son état pendant la session.
Le fonctionnement suit ce besoin. Vous fournissez un Dockerfile, à partir duquel Lambda construit une image et capture un snapshot de l’environnement entièrement initialisé. Chaque appel à run-microvm démarre une MicroVM à partir de ce snapshot, avec un endpoint HTTPS dédié qui accepte HTTP/2, gRPC et WebSocket. Lorsque l’utilisateur s’interrompt, la MicroVM peut être suspendue jusqu’à 8 heures, sans frais de calcul, en conservant sa mémoire et son disque ; elle reprend dans l’état où elle se trouvait dès que le trafic revient.
Les ressources sont définies par une base (2 Go et 1 vCPU par défaut) que la MicroVM peut dépasser jusqu’à quatre fois en pointe, seule la consommation au-delà de la base étant facturée en supplément. L’exemple publié par AWS chiffre à 12,41 $ par développeur et par mois des sandboxes utilisées 2 h 30 par jour, vingt jours par mois, par une équipe de cent développeurs.
Ce modèle n’est pas fait pour héberger une API classique : piloter soi-même le lancement, la suspension et l’arrêt de chaque environnement représente une charge d’exploitation que les Web Functions évitent précisément.
Le coût : décider sur le modèle d’exécution, pas sur le prix
L’argument tarifaire des Web Functions est réel, mais il ne s’applique pas uniformément. Pour le vérifier, nous avons repris les quatre exemples publiés par AWS pour les Web Functions et calculé le coût de la même charge sur une Event Function de 512 Mo en Arm, au tarif de 0,0000133334 $ par Go-seconde (premier palier de la région US East) et 0,20 $ par million de requêtes, hors free tier.
| Charge (exemple AWS) | Requêtes par mois | Durée dont CPU actif | Web Function | Event Function 512 Mo |
|---|---|---|---|---|
| Application SSR | 15 M | 150 ms dont 40 ms | 25,78 $ | 18,00 $ |
| API à forte attente I/O | 10 M | 200 ms dont 50 ms | 19,61 $ | 15,33 $ |
| Middleware d’autorisation | 100 M | 50 ms dont 12 ms | 64,56 $ | 53,33 $ |
| Streaming LLM | 5 M | 3 000 ms dont 200 ms | 33,94 $ | 101,00 $ |
Ce tableau favorise volontairement les Event Functions : nous avons conservé les durées d’AWS alors qu’une fonction de 512 Mo, avec environ un tiers de vCPU, mettrait plus de temps à exécuter la partie calcul de chaque requête. Les exemples d’AWS supposent par ailleurs un environnement actif en permanence pendant tout le mois. Les écarts réels sur les trois premières lignes sont donc plus faibles que ceux affichés, et peuvent s’inverser selon le profil de la charge.
Deux enseignements s’en dégagent néanmoins. Sur les requêtes courtes, les deux modèles restent du même ordre de grandeur : la requête facturée 0,30 $ le million contre 0,20 $ pour une Event Function, et la mémoire facturée pendant les temps morts, compensent l’économie réalisée sur le CPU. Sur les requêtes dominées par l’attente, en revanche, l’écart devient structurel : l’Event Function facture trois secondes de mémoire pour 200 ms de calcul, et la Web Function revient trois fois moins cher.
Le choix doit donc se faire d’abord sur le modèle d’exécution (déclencheur, langage, concurrence, cycle de vie), puis être confirmé par une mesure réelle du ratio entre temps d’attente et temps de calcul de vos requêtes. C’est une démarche FinOps classique : le modèle de facturation le plus avantageux est celui qui correspond au profil mesuré de la charge, pas celui de la grille la plus attractive.
La grille de décision
Sept questions suffisent à orienter la plupart des charges :
- Qu’est-ce qui déclenche le travail ? Un événement mène aux Event Functions, une requête HTTP aux Web Functions, une session qui exécute du code aux MicroVMs.
- Dans quel langage l’application est-elle écrite ? En dehors de Node.js, les Web Functions ne sont pas disponibles, et une API passe par une Event Function derrière API Gateway ou par un conteneur.
- Où les données doivent-elles être traitées ? Si l’hébergement en France est une exigence, seules les Event Functions sont disponibles en région Paris.
- Le code est-il sûr en concurrence ? Sinon, la migration vers une Web Function commence par une revue de l’état global.
- Quelle part de la durée des requêtes est de l’attente ? Plus elle est élevée, plus le gain des Web Functions est important.
- Le trafic est-il intermittent ou stable ? Un trafic intermittent profite du retour à zéro ; un trafic élevé et prévisible relève de Managed Instances ou des conteneurs.
- Le code exécuté est-il de confiance ? Si ce n’est pas le cas, l’isolation au niveau de la machine virtuelle des MicroVMs s’impose.
Quelques cas concrets
| Charge | Modèle recommandé | Raison principale |
|---|---|---|
| API Node.js aujourd’hui servie par API Gateway et un adaptateur | Web Functions | serveur standard, multi-concurrence, suppression de l’adaptateur |
| Site Next.js en rendu côté serveur | Web Functions derrière CloudFront | cache des contenus statiques, endpoint protégé par OAC |
| Endpoint de chat qui relaie un LLM en streaming | Web Functions | l’attente domine, seul le CPU actif est facturé |
| Consommateur SQS, traitement de fichiers S3, tâche planifiée | Event Functions | déclencheur événementiel, reprise sur erreur intégrée |
| API FastAPI ou Spring Boot | Event Functions ou conteneur | Web Functions limité à Node.js |
| Application soumise à un hébergement en France | Event Functions en région Paris | Web Functions et MicroVMs absents de Paris |
| Service à fort volume, stable vingt-quatre heures sur vingt-quatre | Event Functions sur Managed Instances | tarif EC2 et Savings Plans |
| Agent IA qui exécute le code qu’il génère | MicroVMs | isolation VM, état conservé pendant la session |
| Plateforme de CI multi-clients | MicroVMs | isolation entre clients, environnements éphémères |
| Application temps réel en WebSocket | MicroVMs, ou API Gateway WebSocket et Event Functions | la documentation des Web Functions ne prévoit pas de WebSocket |
| Application à audience mondiale, peu dépendante d’une base centrale | Cloudflare Workers, hors AWS | exécution au plus près de chaque utilisateur, mémoire non facturée |
Ces modèles se combinent naturellement au sein d’une même application : une Web Function sert l’API et dépose les traitements longs dans une file SQS, qu’une Event Function consomme ; un produit d’IA expose son interface en Web Function et délègue l’exécution du code généré à des MicroVMs.
Ce que cette gamme dit de la stratégie d’AWS
Lambda subissait la concurrence sur deux fronts. Pour les applications web, la facturation au seul temps CPU était devenue un argument central de ses concurrents : Cloudflare l’applique à ses Workers depuis septembre 2023, et Vercel à ses fonctions depuis juin 2025. Pour l’exécution de code généré par l’IA, de jeunes acteurs spécialisés proposaient des sandboxes à démarrage rapide, souvent construites sur la même technologie de micro-VM. Dans les deux cas, d’autres captaient la valeur d’un modèle d’usage que Lambda ne proposait pas.
La comparaison avec Cloudflare éclaire le choix d’AWS. Les deux offres facturent désormais la requête au même prix, 0,30 $ le million, mais elles y arrivent par des chemins opposés. Cloudflare exécute le code dans des isolates légers de 128 Mo, répartis sur l’ensemble de son réseau, au prix d’un runtime qui n’est pas Node.js et d’une compatibilité encore partielle. AWS conserve un Node.js complet dans des environnements de 2 Go, au prix d’une présence limitée à cinq régions. Cloudflare a d’ailleurs dû créer Smart Placement pour rapprocher l’exécution des bases de données centralisées, alors qu’AWS part de la région, à côté des données. Pour une application dont la latence dépend surtout de la distance aux utilisateurs, Workers garde l’avantage ; pour une application qui enchaîne les requêtes vers une base hébergée sur AWS, Web Functions maintient ces allers-retours au sein d’une même région.
Plutôt que d’étirer un modèle unique pour couvrir tous ces besoins, AWS a choisi de spécialiser Lambda tout en conservant la marque, la console, l’IAM et l’outillage communs. Le renommage des fonctions historiques en Event Functions en est le signal le plus clair : Lambda ne désigne plus un modèle de programmation, mais une famille de services serverless isolés par machine virtuelle.
Pour les équipes DevOps, cette évolution a une conséquence pratique : le choix d’architecture se déplace. Il ne s’agit plus de savoir si une charge « tient » dans Lambda, mais de déterminer quelle forme de Lambda correspond à son déclencheur, à son langage et à son profil d’attente.
Points clés à retenir
- Lambda compte désormais trois formes : Event Functions (le Lambda historique, renommé sans impact sur le code), Web Functions (un serveur HTTP Node.js, multi-concurrent, facturé au CPU actif) et MicroVMs (des sessions isolées dont l’application pilote le cycle de vie).
- Managed Instances n’est pas une quatrième forme, mais un mode d’hébergement des Event Functions sur EC2, pertinent pour les charges élevées et stables, sans retour à zéro.
- Le premier critère de choix est le déclencheur : événement, requête HTTP ou session qui exécute du code.
- Les Web Functions sont limitées à Node.js et absentes de la région Paris, tout comme les MicroVMs.
- Le gain tarifaire des Web Functions est structurel pour les requêtes dominées par l’attente (streaming LLM, API lentes) et marginal pour les requêtes courtes, où la requête coûte 50 % plus cher qu’en Event Function.
- Migrer une fonction existante vers une Web Function impose de vérifier que le code est sûr en concurrence.
Lambda n’est plus un modèle auquel on adapte son application, c’est une gamme dans laquelle on choisit la forme adaptée à chaque charge.
Ressources
- Announcing AWS Lambda Web Functions : l’annonce officielle et la présentation des trois formes
- Documentation Lambda Web Functions : modèle d’exécution, scaling et contrôle d’accès
- Documentation Lambda MicroVMs : images, cycle de vie et cas d’usage
- Documentation Lambda Managed Instances : capacity providers, concurrence et tarification
- Tarification AWS Lambda : grilles et exemples chiffrés des trois formes
- Tarification Cloudflare Workers : facturation au temps CPU et limites du plan payant
