Présentation
AWS Lambda Web Functions a été annoncée comme un nouveau facteur de forme capable d’héberger des applications web HTTP classiques sans nécessiter de réécriture du code en gestionnaire d’événement. La description officielle indique que les développeurs peuvent déployer des serveurs Node.js existants, notamment ceux construits avec Express ou Next.js, et que le service se charge automatiquement du dimensionnement et de la distribution multi‑région.
Fonctionnement et architecture
Chaque environnement d’exécution alloue jusqu’à 128 requêtes concurrentes. Au lieu de facturer la durée totale d’une invocation, la facturation repose sur le temps CPU réellement actif, ce qui réduit les coûts pour les charges à faible utilisation CPU. Le service s’appuie sur l’infrastructure Lambda existante : les conteneurs sont créés à la demande, mais le runtime conserve les sockets HTTP ouverts, permettant de servir plusieurs requêtes sans re‑initialiser le serveur. La distribution s’effectue dans cinq régions au lancement, chaque région disposant d’un point d’entrée dédié qui réplique le code et les dépendances via le même mécanisme de déploiement que les fonctions Lambda classiques.
Analyse des performances et limites
Le plafond de 128 requêtes simultanées impose une contrainte de scalabilité verticale : au-delà de ce seuil, le service crée de nouveaux environnements, ce qui peut introduire une latence de « cold start ». La facturation au temps CPU actif améliore l’efficacité pour les workloads I/O‑bound, mais les applications CPU‑intensives peuvent voir leurs coûts augmenter proportionnellement au temps processeur consommé. L’absence de support explicite pour d’autres runtimes (Python, Java, Go) limite l’adoption aux projets Node.js. Enfin, la disponibilité dans seulement cinq régions signifie que les équipes mondiales doivent vérifier la proximité géographique avant de choisir ce facteur de forme.
Implications pour les développeurs
Le principal avantage réside dans la réutilisation du code existant : aucune adaptation du serveur n’est requise, ce qui accélère les migrations depuis des environnements traditionnels (EC2, containers). Cependant, les équipes doivent adapter leurs pipelines CI/CD pour empaqueter l’application en tant que fonction Lambda, incluant la définition d’un handler factice qui pointe vers le serveur HTTP. La facturation au CPU actif encourage l’optimisation du code (mise en cache, réduction des boucles lourdes) afin de maîtriser les dépenses. Enfin, la limitation régionale incite à planifier des stratégies de réplication ou à combiner Lambda Web Functions avec d’autres services (CloudFront, API Gateway) pour assurer une couverture globale.
