Un tableau de bord appelle AWS, consulte un pipeline CI et renvoie un résumé des déploiements. Une grande partie du temps de réponse peut être passée à attendre ces services. Lambda Web Functions change la manière d’héberger et de facturer ce type de charge HTTP. Le service permet de conserver un serveur Node.js classique tout en partageant son environnement entre plusieurs requêtes.
Les nouveautés annoncées
Annoncé le 12 octobre 2026, Web Functions exécute un serveur HTTP Node.js classique sur Lambda. Express, Hono ou Fastify peuvent écouter sur un port sans adaptateur vers un handler Lambda. Au lancement, le runtime est Node.js 24 sur ARM64, en Virginie du Nord, Ohio, Oregon, à Tokyo et en Irlande. Paris ne figure pas dans cette liste initiale. Annonce AWS.
Le service fournit un endpoint HTTPS, le streaming des réponses et un scaling automatique jusqu’à zéro. Une révision capture le code et sa configuration ; les endpoints dirigent le trafic vers ces révisions. Présentation du service.
Et Python ?
Python n’est actuellement pas pris en charge par Web Functions. Le seul runtime documenté est nodejs24.x. Les runtimes Python restent disponibles sur Lambda classique : une API Python existante ne peut donc pas être déplacée telle quelle vers Web Functions. Runtimes Web Functions · Python sur Lambda.
Python est très utilisé sur Lambda : Datadog comptait 58 % de fonctions Python contre 31 % en Node.js en 2021, parmi ses clients. Ce sont des chiffres historiques, pas des parts de marché actuelles. En 2023, le graphique des invocations donne environ 44 % à Node.js et 28 % à Python. Fonctions déployées et volume d’invocations sont deux mesures différentes ; ces rapports ne permettent pas de désigner un numéro un en 2026. Datadog 2021 · Datadog 2023.
La différence avec Lambda classique
On compare ici les Event Functions à la demande, le modèle Lambda habituel. Lambda Managed Instances constitue une autre option, qui autorise déjà des invocations concurrentes. Modèles de calcul et facturation.
| Point | Lambda classique à la demande | Lambda Web Functions |
|---|---|---|
| Entrée applicative | Handler recevant un événement | Serveur HTTP écoutant sur un port |
| Concurrence dans un environnement | Une invocation à la fois | Plusieurs requêtes HTTP |
| Facturation du calcul | Durée et mémoire allouée | CPU actif et mémoire sur la vie de l’environnement |
| Usage naturel | Consommateurs SQS, événements S3, tâches planifiées | API, rendu serveur, streaming |
AWS ajuste la concurrence effective par environnement. Son plafond configurable atteint 128, sans constituer une garantie de débit. Les réglages maxEnvironments et rateLimit aident à limiter la charge transmise aux bases et aux API dépendantes. Scaling.
Les cas d’usage possibles aujourd’hui
Une API interne de plateforme. Agréger le statut des déploiements, des métadonnées AWS et les résultats des pipelines. Réutiliser un serveur Node.js existant pourrait réduire le travail d’adaptation nécessaire pour l’héberger en serverless.
Le backend d’un portail développeur. Fournir des inventaires d’environnements ou des résumés de releases à une interface web. Les autorisations restent à limiter selon l’utilisateur et l’environnement concernés.
Une passerelle de réponses IA. Transmettre la réponse d’un modèle en streaming tout en gérant l’authentification et le suivi des requêtes. Web Functions héberge la passerelle ; l’inférence du modèle reste un service et un coût séparés.
Ce sont des usages proposés, sans benchmark réalisé ici. Les capacités HTTP et streaming documentées en font des candidats à tester. Charges adaptées.
Dans cette proposition, l’application valide les jetons du fournisseur d’identité et les droits utilisateur. Les appels AWS utilisent les identifiants temporaires d’un rôle d’exécution limité ; l’API CI/CD possède sa propre autorisation de lecture. CloudFront est optionnel pour l’endpoint de base et sert de point d’entrée pour un domaine personnalisé et WAF. Accès à l’endpoint.
Ce que cela change pour les équipes Cloud et DevOps
Build : conserver son framework HTTP, packager le serveur et gérer des releases versionnées. La pondération des révisions permet un déploiement progressif ; les endpoints multirégion ajoutent un routage selon la latence. Il reste à concevoir la localisation des données : une API proche de l’utilisateur peut rester lente si sa base est éloignée. Déploiement.
Run : isoler les données de chaque requête. Une variable globale ne doit pas contenir le jeton ou la réponse d’un utilisateur. Un calcul synchrone lourd bloque l’event loop Node.js et affecte les autres requêtes. Stocker les données durables à l’extérieur et surveiller latence, erreurs et saturation des dépendances. Les cold starts restent possibles après un retour à zéro. Cycle de vie.
FinOps : l’attente d’un service externe consomme peu de CPU, mais la mémoire reste facturée pendant la vie de l’environnement, y compris entre les requêtes. Il faut ajouter requêtes, transferts, logs et dépendances pour comparer le coût complet. Les économies nécessitent des mesures avec un trafic représentatif. Tarification.
Un petit test en Irlande
Pour passer du schéma à la console, une API Node.js a été déployée en eu-west-1. Elle expose /health et /api/platform-summary. Les statuts de déploiement sont fictifs, et une attente asynchrone de 250 ms simule un appel à un service externe.
L’endpoint exige une signature IAM. Le lab limite le scaling à deux environnements, avec un plafond de quatre requêtes par environnement et une limite d’entrée de 100 requêtes/s.
Sans signature, /health renvoie 403 ; avec SigV4, la réponse est 200. Quatre séries de quatre appels parallèles à l’API ont donné 16 réponses réussies sur 16. Le compteur applicatif a observé deux requêtes simultanées dans chacun des deux processus utilisés : le plafond de quatre ne force donc pas Lambda à remplir chaque environnement.
Les logs CloudWatch permettent ensuite de retrouver la route, le statut et le processus qui a servi la requête. Aucun en-tête d’authentification n’est journalisé.
Le gain pour ce type d’API est la mutualisation du serveur HTTP : pendant qu’une requête attend, le même processus peut en traiter une autre. Avec Lambda classique à la demande, chaque invocation simultanée occupe un environnement distinct.
Comment l’évaluer concrètement
Partir d’une API de consultation en Irlande et comparer la même logique métier sur les deux modèles. Tester une réponse JSON minimale, des appels parallèles et une route gourmande en CPU, avec un trafic espacé, régulier puis en pic. Mesurer p50/p95/p99, débit réussi, erreurs et coût complet par requête réussie.
Web Functions est une option à étudier pour un service HTTP Node.js qui passe beaucoup de temps à attendre. Les consommateurs d’événements existants restent adaptés aux Event Functions. Le choix dépend des résultats mesurés sur l’application : facilité de déploiement, comportement en charge et coût avec un trafic réel.
Cloud, DevOps et agents IA. Le journal Kloud.
Retour au journal