AWS Lambda Web Functions permet aux développeurs de déployer des applications HTTP Node.js standard sans les réécrire sous forme de gestionnaires d’événements. Son modèle de requêtes concurrentes, sa facturation au CPU actif et sa mise à l’échelle gérée offrent de nouvelles options d’hébergement, mais des limites de réseau, de sécurité et d’exploitation déterminent les cas où il convient.
Un développeur crée une API avec Express ou Fastify. L’application démarre un serveur HTTP, écoute sur un port et traite les requêtes entrantes. Pour exécuter cette application sur AWS Lambda traditionnel, il faut généralement l’adapter à une interface de gestionnaire d’événements (event handler).
Le 12 octobre 2026, AWS a lancé Lambda Web Functions, qui permet aux développeurs de déployer un serveur HTTP Node.js classique directement sur Lambda. Au lancement, AWS a rendu le service disponible dans cinq régions : US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) et Europe (Ireland). AWS peut ajouter des régions, vérifiez donc sa liste à jour avant de bâtir vos plans autour du service.
Les Web Functions introduisent aussi un modèle d’exécution différent. Plusieurs requêtes HTTP peuvent partager un environnement d’exécution, et la facturation distingue la consommation de CPU actif de la mémoire allouée pendant toute la durée de vie de l’environnement. Ces capacités font de Lambda une option pour davantage d’applications web, mais elles ne dispensent pas de choisir la bonne architecture d’hébergement.
Qu’est-ce qui change par rapport à Lambda traditionnel ?
AWS appelle désormais son modèle de gestionnaire Lambda existant Event Functions. Ce changement de nom n’oblige pas à réécrire les fonctions existantes.
Une Event Function reçoit un événement, exécute son gestionnaire et renvoie un résultat. Un environnement d’exécution standard d’Event Function traite une invocation à la fois. Une Web Function exécute à la place un serveur HTTP Node.js ordinaire. Lambda achemine le trafic HTTP vers ce serveur, qui peut traiter des requêtes concurrentes.
| Caractéristique | Event Functions | Web Functions |
|---|---|---|
| Modèle de programmation | Gestionnaire d’événements | Serveur HTTP Node.js à l’écoute sur un port |
| Charges de travail typiques | Événements, files d’attente, tâches planifiées et gestionnaires d’API | API HTTP, applications web, rendu côté serveur et streaming |
| Concurrence par environnement | Une invocation à la fois | Plusieurs requêtes HTTP |
| Base de facturation du calcul | Durée de l’invocation | Consommation de CPU actif |
| Base de facturation de la mémoire | Durée de l’invocation | Durée de vie de l’environnement d’exécution |
| Mise à l’échelle | Mise à l’échelle gérée des invocations | Mise à l’échelle HTTP gérée, y compris jusqu’à zéro (scale-to-zero) |
Les deux modèles conservent des finalités distinctes. Une application peut utiliser les Web Functions pour une API et garder les Event Functions pour le traitement de files d’attente ou les tâches planifiées. Les règles de délai d’expiration (timeout) des Event Functions sont un sujet à part, traité dans notre article sur le délai d’expiration de 90 minutes de Lambda (en anglais).
Source : AWS, Announcing AWS Lambda Web Functions, 12 octobre 2026.
Comment les requêtes concurrentes changent l’exécution
Le principal changement est qu’un seul environnement d’exécution peut traiter de nombreuses requêtes à la fois, comme le fait un serveur web ordinaire. Au lancement, les Web Functions prennent en charge Node.js 24 sur Arm64, et chaque environnement d’exécution dispose de 2 vCPU et de 2 Go de mémoire. Contrairement à un environnement d’Event Function traditionnel, un environnement de Web Function peut servir plusieurs requêtes simultanément.
AWS ajuste dynamiquement le nombre de requêtes traitées par un environnement en fonction de l’utilisation des ressources observée. Le paramètre maxConcurrencyPerEnvironment définit une limite supérieure comprise entre 1 et 128, et sa valeur par défaut est 64. Cette valeur n’est pas une concurrence garantie. Lambda peut retenir une limite effective plus basse lorsque l’utilisation du CPU ou de la mémoire rend des requêtes supplémentaires inadaptées.
Cela peut profiter aux applications dominées par les E/S asynchrones. Par exemple, une API Node.js peut passer une grande partie du temps de traitement d’une requête à attendre des interrogations de base de données ou des services externes. Pendant qu’une requête attend, la boucle d’événements (event loop) peut traiter d’autres requêtes.
Le travail synchrone gourmand en CPU se comporte différemment. Si une requête bloque la boucle d’événements, les autres requêtes qui partagent ce processus peuvent elles aussi être retardées.
Le partage d’un même processus entre les requêtes pose aussi un problème d’état. Les informations propres à une requête ne doivent pas être stockées dans des variables globales mutables partagées. Les caches, les compteurs et les autres objets partagés demandent un traitement approprié lorsque des opérations asynchrones s’entrelacent.
Une application écrite pour un serveur Node.js classique tient peut-être déjà compte de ces conditions. Les développeurs doivent tout de même vérifier son comportement réel dans l’environnement Lambda géré.
Sources : AWS, Execution environment lifecycle, Scaling behavior et Runtime support.
Que signifie la facturation au CPU actif ?
La facturation au CPU actif signifie que vous payez le temps CPU que votre code utilise réellement, et non le temps qu’une requête passe à attendre d’autres systèmes. Les clients paient les requêtes, la consommation de CPU actif, l’utilisation de la mémoire pendant la durée de vie de l’environnement d’exécution et les transferts de données applicables. Cela diffère du modèle de durée traditionnel de Lambda, qui inclut le temps qu’une invocation passe à attendre des opérations en aval.
Prenons une requête d’API qui effectue un bref calcul puis attend la réponse d’une base de données. Avec les Web Functions, la période d’attente peut consommer peu de CPU actif. En revanche, la facturation de la mémoire continue tant que l’environnement d’exécution existe, y compris pendant les périodes d’inactivité entre les requêtes. Un point de terminaison (endpoint) peut redescendre à zéro après l’arrêt du trafic, mais un environnement ne disparaît pas nécessairement immédiatement après chaque requête.
Cette distinction rend les Web Functions potentiellement intéressantes pour certaines applications à forte intensité d’E/S. Elle n’établit pas que le service coûte moins cher pour toutes les applications. Une comparaison des coûts doit prendre en compte les profils de trafic, la durée moyenne des requêtes, l’utilisation du CPU, la consommation de mémoire, les transferts de données et le comportement de la plateforme d’hébergement actuelle. Les applications dont les charges de travail sont durablement gourmandes en CPU peuvent avoir une économie différente de celle des applications dominées par les attentes réseau.
Source : AWS, Lambda Web Functions overview.
Comment fonctionnent le déploiement et la mise à l’échelle
Une Web Function contient des révisions et des points de terminaison. Une révision est un instantané immuable du code et de la configuration de l’application. Un point de terminaison fournit le point d’entrée HTTP et achemine les requêtes vers une ou deux révisions selon sa configuration de trafic.
Cette séparation permet des déploiements contrôlés. Les équipes peuvent créer une nouvelle révision, la tester et lui diriger une partie du trafic.
Appel du client
Chaque point de terminaison de Web Function possède un nom de domaine accessible publiquement.
Avec IamAuth, Lambda exige des requêtes signées et dûment autorisées.
Avec ApplicationManaged, Lambda transmet les requêtes sans authentifier l’appelant.
Choix d’une révision
Un point de terminaison fournit le point d’entrée HTTP et achemine les requêtes vers une ou deux révisions selon sa configuration de trafic.
Les équipes peuvent créer une nouvelle révision, la tester et lui diriger une partie du trafic.
Plusieurs requêtes à la fois
Contrairement à un environnement d’Event Function traditionnel, un environnement de Web Function peut servir plusieurs requêtes simultanément.
Le paramètre maxConcurrencyPerEnvironment définit une limite supérieure comprise entre 1 et 128, et sa valeur par défaut est 64.
Lambda peut retenir une limite effective plus basse lorsque l’utilisation du CPU ou de la mémoire rend des requêtes supplémentaires inadaptées.
Réponse et délai
Lambda transmet l’intégralité du corps de la requête entrante avant de livrer la réponse de l’application.
Les requêtes de Web Function ont un délai d’expiration par défaut de 30 secondes et un maximum configurable de 900 secondes, soit 15 minutes.
S’il expire après l’envoi des en-têtes de réponse, le client peut recevoir une réponse tronquée plutôt qu’une erreur d’application propre.
AWS fournit trois principaux paramètres de mise à l’échelle.
| Paramètre | Rôle |
|---|---|
maxConcurrencyPerEnvironment | Limite supérieure des requêtes concurrentes dans un environnement |
maxEnvironments | Nombre maximal facultatif d’environnements par point de terminaison dans chaque région |
rateLimit | Limite facultative d’arrivée des requêtes par point de terminaison dans chaque région |
Le service applique aussi des limites au niveau du compte, notamment la capacité en vCPU par région et des quotas de débit de requêtes. Augmenter un paramètre de point de terminaison ne passe pas outre ces quotas de compte.
Lorsqu’un point de terminaison dépasse une limite de débit de requêtes ou n’a plus de capacité de service disponible, Lambda peut renvoyer des réponses HTTP 429. D’autres cas sont à prendre en compte. Régler rateLimit sur zéro désactive le trafic et produit une réponse HTTP 503 avec un indicateur d’erreur de plateforme spécifique. AWS peut aussi renvoyer HTTP 503 lorsqu’il déleste de la charge pour protéger le service.
Les clients ne doivent réessayer que lorsque c’est approprié, en attendant plus longtemps après chaque échec et en ajoutant un délai aléatoire (backoff et jitter). Les opérations d’écriture peuvent nécessiter des clés d’idempotence ou une déduplication afin que les nouvelles tentatives (retries) ne répètent pas les effets métier.
Une révision déployée n’est pas forcément une application qui fonctionne
AWS distingue les états des ressources de révision et de point de terminaison de l’état de préparation réel de l’application. Une révision peut devenir active même si son serveur HTTP ne démarre pas correctement.
Après le déploiement, les équipes doivent envoyer une vraie requête HTTP, examiner les journaux (logs) de l’application et confirmer que le point de terminaison sert la réponse attendue. Pour les déploiements en production, un déploiement pondéré des révisions et un chemin de retour arrière (rollback) vérifié sont plus fiables que de supposer que la création des ressources équivaut à un déploiement réussi de l’application.
Sources : AWS, Scaling behavior et Core concepts.
Le streaming fonctionne, avec des limites de protocole
Les Web Functions prennent en charge le streaming des réponses HTTP. Cela peut aider les applications à livrer du contenu rendu côté serveur, des résultats d’API incrémentaux ou des sorties générées par IA au fur et à mesure de leur disponibilité.
Le chemin des requêtes et des réponses comporte toutefois une limite importante. AWS documente un comportement HTTP/1.1 semi-duplex (half-duplex). Lambda transmet l’intégralité du corps de la requête entrante avant de livrer la réponse de l’application.
Les applications doivent donc finir de lire le corps d’une requête avant d’écrire leur réponse. Cela compte pour les conceptions qui prévoient un streaming bidirectionnel pendant qu’un client envoie encore des données.
Les mises à niveau WebSocket (WebSocket upgrades) ne sont pas prises en charge. Les événements envoyés par le serveur (server-sent events) peuvent convenir au streaming unidirectionnel du serveur vers le client, mais les applications qui exigent une communication WebSocket bidirectionnelle persistante ont besoin d’une autre architecture prise en charge.
Les requêtes de Web Function ont un délai d’expiration par défaut de 30 secondes et un maximum configurable de 900 secondes, soit 15 minutes. Le délai d’expiration doit couvrir la réception du corps de la requête et la livraison de la réponse. S’il expire après l’envoi des en-têtes de réponse, le client peut recevoir une réponse tronquée plutôt qu’une erreur d’application propre.
Source : AWS, Configuring networking for Web Functions.
Le déploiement multirégion et la connectivité VPC ne sont pas interchangeables
AWS prend en charge des points de terminaison multirégions qui répliquent les révisions de l’application dans des régions prises en charge sélectionnées et acheminent les requêtes en fonction de la latence réseau. Cela peut aider les applications à servir des utilisateurs répartis géographiquement.
Toutefois, déployer l’application dans plusieurs régions ne réplique pas automatiquement ses bases de données, ses sessions, ses secrets ni ses dépendances en aval. Les équipes doivent s’assurer que chaque région participante peut accéder aux ressources nécessaires pour servir les requêtes.
Un déploiement multirégion peut aussi échouer à mi-parcours. Une mise à jour de point de terminaison peut réussir dans une région et échouer dans une autre. AWS recommande de vérifier l’état de mise à jour de chaque région plutôt que de considérer l’état global du point de terminaison comme la preuve que chaque région a reçu la même révision.
Une limite importante pour les ressources privées
Les Web Functions prennent aussi en charge la connectivité sortante vers des ressources situées dans un Amazon VPC grâce à un connecteur réseau de sortie (egress network connector). Les points de terminaison sont de trois types. Un point de terminaison HomeRegion sert le trafic de la région d’origine uniquement, tandis que les points de terminaison MultiRegion et PerRegion servent le trafic de plusieurs régions.
Au 6 novembre 2026, ces connecteurs ne sont pris en charge qu’avec les points de terminaison HomeRegion.
AWS ne prend pas en charge l’association d’un connecteur de sortie VPC à des révisions servies par des points de terminaison MultiRegion ou PerRegion. Une application qui exige un accès direct à une base de données privée par un tel connecteur ne peut donc pas supposer qu’elle pourra aussi utiliser la distribution multirégion intégrée des points de terminaison des Web Functions. Cette contrainte doit être résolue lors du choix de l’architecture, et non après le déploiement.
La connectivité de sortie VPC ne rend pas non plus privé le point de terminaison HTTPS entrant de la Web Function. L’accès entrant et la connectivité réseau sortante sont des questions distinctes.
Entrée publique
Chaque point de terminaison de Web Function possède un nom de domaine accessible publiquement.
L’authentification IAM ne fait pas du point de terminaison une ressource de réseau privé.
Sortie privée possible
Les Web Functions prennent aussi en charge la connectivité sortante vers des ressources situées dans un Amazon VPC grâce à un connecteur réseau de sortie (egress network connector).
La connectivité de sortie VPC ne rend pas non plus privé le point de terminaison HTTPS entrant de la Web Function.
L’accès entrant et la connectivité réseau sortante sont des questions distinctes.
Seul HomeRegion
AWS ne prend pas en charge l’association d’un connecteur de sortie VPC à des révisions servies par des points de terminaison MultiRegion ou PerRegion.
Une application qui exige un accès direct à une base de données privée par un tel connecteur ne peut donc pas supposer qu’elle pourra aussi utiliser la distribution multirégion intégrée des points de terminaison des Web Functions.
Décider tôt
Cette contrainte doit être résolue lors du choix de l’architecture, et non après le déploiement.
Toutefois, déployer l’application dans plusieurs régions ne réplique pas automatiquement ses bases de données, ses sessions, ses secrets ni ses dépendances en aval.
Sources : AWS, Configuring networking for Web Functions, Core concepts et Best practices for Lambda Web Functions.
La sécurité commence au point de terminaison public
Chaque point de terminaison de Web Function possède un nom de domaine accessible publiquement. AWS propose deux approches d’authentification.
Avec IamAuth, Lambda exige des requêtes signées et dûment autorisées. Avec ApplicationManaged, Lambda transmet les requêtes sans authentifier l’appelant. L’application ou un service en amont doit mettre en œuvre l’authentification et l’autorisation nécessaires.
L’authentification IAM ne fait pas du point de terminaison une ressource de réseau privé. Pour les applications publiques, les développeurs doivent aussi traiter la validation des entrées, les abus de débit, l’autorisation des requêtes et la protection des informations sensibles.
Les points de terminaison de Web Function ne prennent en charge ni les noms de domaine personnalisés ni l’association directe à AWS WAF. Amazon CloudFront peut être placé devant une Web Function pour fournir un domaine personnalisé, la mise en cache et la protection AWS WAF.
Pour un point de terminaison IamAuth, AWS recommande le contrôle d’accès à l’origine (origin access control, OAC) de CloudFront, afin que CloudFront signe ses requêtes vers l’origine. Avec d’autres points d’entrée frontaux (front doors), le point de terminaison reste directement accessible, si bien que l’application doit vérifier un secret partagé ou un jeton. Sans restrictions d’origine adaptées, des requêtes directes peuvent contourner le point d’entrée frontal prévu.
Les applications de navigateur exigent aussi une configuration appropriée du partage de ressources entre origines (Cross-Origin Resource Sharing, CORS). Lambda n’ajoute pas d’en-têtes CORS pour les Web Functions, l’application ou son point d’entrée frontal doit donc les gérer. CORS n’est pas un mécanisme d’authentification.
Sources : AWS, Best practices for Lambda Web Functions et Configuring networking for Web Functions.
Quand les développeurs devraient-ils envisager les Web Functions ?
Le choix doit suivre le comportement réel de la charge de travail.
| Charge de travail | Approche à évaluer |
|---|---|
| API Node.js avec des appels asynchrones à la base de données ou au réseau | Web Functions |
| Rendu côté serveur avec Node.js | Web Functions |
| Streaming de réponses HTTP ou événements envoyés par le serveur | Web Functions, dans les limites de délai d’expiration et de protocole |
| Traitement de files d’attente et tâches d’arrière-plan planifiées | Event Functions |
| Communication WebSocket persistante | Une autre architecture d’hébergement compatible WebSocket |
| Service web nécessitant un accès VPC privé direct et une distribution multirégion intégrée | Une autre conception ou approche d’hébergement |
| Applications nécessitant des runtimes non pris en charge ou des ressources d’exécution personnalisées | Hébergement en conteneurs ou autre service de calcul adapté |
Au lancement, les Web Functions ne prennent en charge que Node.js. Les applications qui utilisent un autre runtime, qui exigent d’autres ressources de calcul ou qui dépendent d’un comportement réseau non pris en charge ne doivent pas être forcées dans le service simplement parce qu’il est serverless. Les applications ECS ou Fargate existantes répondent peut-être déjà efficacement à leurs besoins. Une migration doit découler d’avantages opérationnels ou économiques démontrés.
Un test ciblé de préparation à la production
Avant d’adopter les Web Functions, choisissez un service HTTP représentatif hors production. Vérifiez que le serveur démarre correctement et écoute sur le point de terminaison requis. Testez les requêtes concurrentes, l’état partagé, les connexions aux bases de données et le blocage de la boucle d’événements. Mesurez le comportement réel de la facturation du CPU et de la mémoire sous un trafic réaliste.
Vérifiez la limitation de débit (throttling), les démarrages à froid (cold starts), la gestion des délais d’expiration, les réponses en streaming et la sûreté des nouvelles tentatives côté client. Validez ensuite l’authentification du point de terminaison, la protection de l’origine CloudFront, les exigences VPC et le comportement du déploiement régional. Enfin, déployez une deuxième révision et prouvez que le trafic peut être ramené à la version précédente qui fonctionnait.
Ces vérifications aident à distinguer une démonstration réussie d’une application exploitable de manière fiable.
Ce que les Web Functions changent réellement
AWS Lambda Web Functions amène des applications web Node.js familières dans Lambda sans exiger le modèle de gestionnaire traditionnel. Le traitement HTTP concurrent, la mise à l’échelle gérée et la facturation au CPU actif en font une nouvelle option d’hébergement significative.
Les limites comptent autant que les fonctionnalités. Les applications doivent rester sûres sous des requêtes concurrentes. La facturation de la mémoire continue tant que les environnements existent.
Les mises à niveau WebSocket ne sont pas disponibles. Les connecteurs de sortie VPC ne peuvent pas, pour l’instant, être combinés avec les types de points de terminaison multirégions intégrés.
La décision pratique ne consiste pas à savoir si Lambda peut exécuter un serveur web ordinaire.
Elle consiste à savoir si le modèle d’exécution, de réseau et d’exploitation des Web Functions convient mieux à l’application que ses solutions d’hébergement existantes.
Références et lectures complémentaires
- AWS, Announcing AWS Lambda Web Functions. 12 octobre 2026. Régions de lancement, runtime et les trois formes de fonctions Lambda.
- AWS, Lambda Web Functions overview. Modèle de programmation, facturation et charges de travail prises en charge.
- AWS, Core concepts. Révisions, points de terminaison et traitement des requêtes.
- AWS, Scaling behavior. Concurrence dynamique, quotas et limitation de débit.
- AWS, Execution environment lifecycle. Sécurité en situation de concurrence, arrêt et réutilisation des environnements.
- AWS, Configuring networking. Streaming HTTP, restrictions VPC, connectivité des points de terminaison et CORS.
- AWS, Best practices. Sécurité, comportement des nouvelles tentatives, vérification des déploiements et opérations multirégions.
- AWS, Runtime support. Exigences du runtime Node.js et mémoire.
Sources vérifiées le 5 novembre 2026 et revérifiées le 6 novembre 2026. Les capacités et limites techniques reflètent la documentation d’AWS à ces dates, et un nouveau service évolue vite : vérifiez donc les sources ci-dessus avant d’agir. Les implications en matière de coûts et de performances relèvent de l’analyse d’architecture, et non de résultats de benchmarks indépendants de TechiesJournal.