AWS a annoncé AWS Lambda Web Functions, un nouveau mode au sein de Lambda qui permet d’exécuter directement des applications web et des serveurs HTTP standard, sans réécrire le code pour l’adapter au modèle traditionnel des gestionnaires d’événements. Il est possible de déployer des applications conçues avec Express, Hono, Fastify ou Next.js, ou avec n’importe quel framework Node.js, au moyen d’une seule commande, sans adaptateurs spécifiques ni gestion d’infrastructure supplémentaire.
Le service cible les applications web, les interfaces de programmation, le rendu côté serveur et les charges HTTP interactives qui traitent des requêtes simultanées et des opérations intensives en entrées-sorties.
Un modèle d’exécution différent au sein de Lambda
AWS propose désormais trois modèles d’exécution distincts au sein de Lambda, tous fondés sur la technologie d’isolation Firecracker. Event Functions reste adapté au traitement des événements, à la consommation de messages et aux invocations générées par les services AWS : le gestionnaire reçoit un événement unique et renvoie une réponse selon le modèle traditionnel.
Les Web Functions utilisent quant à elles un modèle natif pour HTTP, dans lequel l’application écoute sur un port et traite les requêtes standard. Un même environnement d’exécution peut traiter jusqu’à 128 requêtes simultanées. Le troisième modèle, Lambda MicroVMs, fournit des environnements isolés, un état persistant et un cycle de vie géré par le client pour exécuter du code non fiable ou généré par l’utilisateur.
Ce qui change concrètement pour les développeurs
AWS affirme que les Web Functions réduisent la nécessité d’assembler plusieurs composants pour distribuer mondialement une application web. Le service prend en charge la mise à l’échelle, la réplication entre régions et le routage fondé sur la latence, tandis que le code reste plus proche du serveur HTTP que le développeur exécute localement.
La facturation des Web Functions repose sur le temps d’utilisation du processeur, tandis que la mémoire est facturée pendant toute la durée d’existence de l’environnement d’exécution. Ainsi, le temps passé par l’application à attendre une requête de base de données ou l’appel d’une interface de programmation consomme peu de temps processeur. Ce modèle peut donc convenir aux charges fortement dépendantes des entrées-sorties, telles que le rendu côté serveur, les interfaces de programmation et les points de terminaison d’inférence d’intelligence artificielle qui diffusent les jetons.
Cela ne signifie pas que le coût sera automatiquement inférieur pour chaque application : le résultat dépend du modèle d’utilisation, de la durée de vie des environnements, de la consommation mémoire et du volume des requêtes.
Déploiement, distribution et versions
AWS CLI utilise une commande telle que aws lambda-web deploy pour empaqueter le code, créer une Web Function, déployer une première révision et associer un point de terminaison HTTPS. L’application peut être déployée dans plusieurs régions, telles que us-east-1, eu-west-1 et ap-northeast-1, afin que Lambda achemine les requêtes via une adresse mondiale unique vers la région présentant la latence la plus faible, selon les meilleures capacités disponibles.
Le service traite chaque version comme un instantané immuable du code. Les points de terminaison permettent également de répartir le trafic entre les versions, notamment au moyen d’un déploiement progressif de type canary qui dirige, par exemple, 90 % des requêtes vers la version actuelle et 10 % vers la nouvelle version.
Intégration avec CloudFront et disponibilité initiale
Un point de terminaison Web Function peut être utilisé comme origine pour Amazon CloudFront : les ressources statiques sont alors mises en cache sur le réseau, tandis que les requêtes dynamiques sont envoyées à la fonction web. AWS prend également en charge l’association du contrôle d’accès à l’origine de CloudFront au point de terminaison, afin d’autoriser uniquement le domaine spécifié à l’appeler, d’éviter d’exposer le point de terminaison et de ne pas ajouter de mécanisme d’autorisation personnalisé dans l’application.
Le service est disponible au lancement dans US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) et Europe (Ireland). Il fonctionne initialement avec Node.js 24 (nodejs24.x) sur Arm64, et prend en charge la connexion à Amazon VPC pour accéder aux ressources situées dans les réseaux privés virtuels.