Lambda Web Functions exécute un serveur HTTP standard sans réécriture en handler d’événement

12 octobre 2026. AWS annonce sur son blog Lambda Web Functions. Trois. C’est désormais le nombre de facteurs de forme de Lambda, tous bâtis sur Firecracker. 128 requêtes concurrentes. C’est ce qu’absorbe un seul environnement d’exécution d’une Web Function. Pourquoi c’est important : depuis le lancement de Lambda en 2014, déployer du Node.js sur le service obligeait à traduire un serveur HTTP en handler qui reçoit un événement et renvoie une réponse. Lambda Web Functions supprime cette traduction — vous déployez le serveur que vous avez déjà, et la facturation suit le CPU réellement consommé au lieu du temps passé à attendre une requête de base de données.

Le troisième facteur de forme de Lambda

Lambda se découpe désormais en trois modèles de programmation, qui partagent la même isolation Firecracker et le même modèle opérationnel. Les Event Functions sont les Lambda que l’on connaît : un handler mono-concurrent, piloté par événement, facturé au temps d’exécution mural. Les Web Functions adoptent un modèle HTTP natif : votre code écoute sur un port et traite des requêtes HTTP standard, avec une exécution multi-concurrente et une facturation au CPU actif. Les MicroVMs fournissent des environnements sandbox isolés et avec état, au cycle de vie géré par le client, pour du code non fiable.

Les trois se complètent. Une même application peut employer des Event Functions pour le traitement asynchrone en arrière-plan, des Web Functions pour l’API publique et le rendu serveur, et des MicroVMs pour exécuter du code interactif non fiable, le tout dans le même compte AWS.

Le point de bascule est la concurrence. Chaque environnement d’exécution d’une Web Function absorbe jusqu’à 128 requêtes simultanées, de sorte qu’un pic de trafic réutilise les environnements déjà chauds au lieu de mapper chaque requête vers un nouveau. C’est l’inverse du modèle de l’event function classique, où une requête concurrente supplémentaire a longtemps signifié un environnement froid supplémentaire.

Ce que change la facturation au CPU actif

La facturation est l’autre rupture. Une Web Function mesure le temps CPU que votre code consomme : le temps passé à attendre une requête de base de données ou un appel d’API coûte très peu de CPU. La mémoire, elle, est facturée tant que l’environnement d’exécution existe. Pour les charges riches en E/S — rendu serveur, backends d’API, endpoints d’inférence IA qui diffusent des jetons en continu — cette facturation au CPU actif peut réduire le coût de calcul par rapport à un handler qui paie chaque milliseconde d’attente.

Concrètement, le seul écart entre votre code local et la Web Function tient à une variable d’environnement. Lambda définit AWS_LAMBDA_HTTP_ENDPOINT avec l’hôte et le port sur lesquels votre serveur doit écouter :

import express from 'express';

const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');

app.get('/', (req, res) => {
  res.json({ message: 'Hello from Lambda Web Functions!' });
});

app.listen(port, host, () => {
  console.log(`Server running on port ${port}`);
});

Localement, vous la fixez vous-même : AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js. Aucun adapter, aucun wrapper propre à Lambda. Les frameworks annoncés couvrent Express, Hono, Fastify et Next.js — en pratique, tout serveur Node.js qui écoute sur un port.

Un déploiement en une commande, des révisions immuables

Le déploiement tient en une ligne, sans provisionnement préalable :

aws lambda-web deploy --name my-web-app --code ./my-app

La CLI empaquète le code, crée la Web Function, publie sa première révision, attache un endpoint et renvoie une URL HTTPS en moins d’une minute. Une révision est un instantané immuable du code ; un endpoint est l’URL qui route le trafic vers une révision, ou le répartit entre plusieurs. Mettre à jour le code revient à relancer la même commande : la CLI détecte la fonction existante, téléverse une nouvelle révision et la branche sur l’endpoint.

Pour un déploiement progressif, on bascule le trafic entre révisions par un simple appel :

aws lambda-web update-web-function-endpoint \
  --function-name my-web-app \
  --endpoint-name dev \
  --auto-deployment-mode Disabled \
  --revision-weights '[{"revisionId": "<current>", "weight": 90}, {"revisionId": "<new>", "weight": 10}]'

Ce canary envoie 90 % du trafic vers la révision en place et 10 % vers la nouvelle — l’équivalent, en une commande, du blue/green ou du canary release que les équipes assemblent habituellement à coups de CodeDeploy ou de routage pondéré.

La distribution multi-région devient un drapeau

La partie la plus remarquable pour un SRE est la distribution globale. Déployer sur trois régions tient dans un argument :

aws lambda-web deploy --name my-web-app --code ./my-app \
  --regions us-east-1,eu-west-1,ap-northeast-1

Lambda réplique le code sur les trois régions et configure automatiquement un routage par latence, sur une URL globale unique (<domaine>.lambda-web.global.on.aws). Chaque requête est dirigée, au mieux, vers la région la plus proche de l’appelant. Ce qui prenait hier un CloudFront, des déploiements régionaux et une Route 53 latency-based se résume à une liste de régions dans la commande de déploiement.

Un modèle de concurrence et de facturation différent

Derrière le déploiement simplifié, la vraie nouveauté est le modèle d’exécution. Une Event Function classique traite une invocation à la fois et facture le temps d’exécution mural ; une Web Function accepte jusqu’à 128 requêtes simultanées dans le même environnement chaud et facture le CPU actif. Deux conséquences pratiques en découlent.

La première concerne les cold starts. Un pic de trafic partage des environnements déjà démarrés au lieu d’en provisionner un par requête, si bien que la latence de démarrage à froid cesse d’être payée à chaque requête concurrente supplémentaire. La seconde concerne la facturation : l’attente d’E/S ne coûte presque plus rien. Une application qui passe l’essentiel de son temps à interroger une base de données ou à diffuser des jetons voit son coût suivre le CPU qu’elle brûle, et non le temps qu’elle attend — c’est exactement l’inverse du modèle mural, où une requête qui dort est facturée au même titre qu’une requête qui calcule.

Ce basculement a un corollaire de conception. Sur le modèle événementiel, on optimisait pour ne jamais laisser un handler inactif ; sur le modèle HTTP natif, on optimise pour que le serveur réponde vite et rende la main, puisque c’est le CPU consommé — pas la durée de la requête — qui fixe le coût. Les équipes qui migrent gagnent donc plus à réduire les cycles brûlés qu’à réduire les millisecondes de latence.

Verdict

Lambda Web Functions vise un créneau précis : l’application HTTP interactive, riche en attente E/S, que l’on déforme aujourd’hui pour la faire entrer dans le moule événementiel. Si vous déployez une API Node.js, un rendu serveur ou un endpoint qui streame des jetons, testez-le — vous gardez le serveur que vous avez, vous gagnez la concurrence et vous ne payez plus l’attente. Si votre charge est de l’event processing pur — files, consommateurs de SQS, déclencheurs S3 — restez sur les Event Functions : le modèle événementiel y reste le bon outil, et la migration n’apporterait rien. Si vous orchestrez du code non fiable ou à état, c’est le rôle des MicroVMs, pas des Web Functions. L’essentiel est ailleurs : AWS converge vers le même constat que Cloudflare Workers, Deno Deploy et Vercel — le serveur HTTP standard est redevenu l’unité de calcul qui compte, et c’est l’infrastructure qui s’adapte au code, plus l’inverse.

Références

• AWS — Announcing AWS Lambda Web Functions (12 octobre 2026)