AWS Lambda Web Functions porta Express e Next.js nel serverless nativo

📌 In Sintesi

• AWS Lambda Web Functions esegue applicazioni HTTP standard senza trasformarle nel tradizionale modello event-handler di Lambda.
• Ogni ambiente può gestire fino a 128 richieste concorrenti e il billing separa CPU attiva e memoria, riducendo il peso economico delle attese I/O.
• AWS automatizza distribuzione multi-Region, routing per latenza e deployment progressivi, portando Lambda più vicino a container e piattaforme web serverless.

AWS cambia uno dei presupposti storici di Lambda e permette di eseguire server HTTP tradizionali direttamente dentro il proprio ambiente serverless. Con Lambda Web Functions un’applicazione costruita con Express, Hono, Fastify, Next.js o altri framework Node.js può continuare ad ascoltare su una porta e gestire normali richieste HTTP senza essere riscritta attorno al classico handler event-driven. La differenza architetturale è sostanziale: ogni ambiente caldo può elaborare fino a 128 richieste concorrenti, AWS replica automaticamente l’applicazione nelle Region selezionate e il costo della CPU viene calcolato sul tempo effettivamente utilizzato invece che sulle attese verso database o servizi esterni. Dopo avere già spinto Lambda fino a 90 minuti per alcuni workload asincroni, Amazon ora interviene sull’altro limite storico del servizio: il modo in cui deve essere scritto il software che vi gira.

Lambda smette di imporre il modello handler alle applicazioni web

Nel lancio ufficiale di AWS Lambda Web Functions Amazon distingue ora tre modalità sotto la stessa infrastruttura Lambda. Le tradizionali funzioni vengono rinominate Lambda Event Functions e mantengono il paradigma nel quale un evento entra nell’handler, viene elaborato e produce una risposta. Le nuove Web Functions utilizzano invece un modello HTTP nativo: il processo apre una porta, riceve più richieste contemporaneamente e si comporta come un normale server web. Lambda MicroVMs copre infine gli ambienti isolati e stateful destinati anche all’esecuzione di codice non affidabile. La separazione rende esplicito quanto Lambda si sia allontanato dall’idea originaria della piccola funzione monouso: AWS sta trasformando il servizio in una famiglia di primitive compute differenti costruite sopra la stessa tecnologia di isolamento Firecracker.

Leggi anche: AWS porta gli agenti AI nel ciclo software con AgentCore, Quick e Codex

Fino a 128 richieste concorrenti cambiano il rapporto tra Lambda e il web

Il cambiamento più interessante riguarda la concorrenza. Nel modello Lambda tradizionale ogni execution environment processa una singola invocazione alla volta; Web Functions consente invece a un ambiente caldo di gestire fino a 128 richieste simultanee. Per API, server-side rendering e applicazioni con molta attesa I/O significa utilizzare meglio processi già inizializzati invece di moltiplicare necessariamente gli ambienti a ogni picco di traffico. È anche una risposta indiretta al problema dei cold start: più richieste possono condividere un processo già disponibile. AWS non elimina quindi il concetto di ambiente effimero, ma ne aumenta fortemente la densità di utilizzo. Per sviluppatori abituati a Express o Fastify, la conseguenza pratica è ancora più semplice: il codice locale e quello distribuito sul cloud diventano molto più simili, perché non serve più adattare routing e lifecycle al formato proprietario dell’handler Lambda.

Il billing sulla CPU attiva premia API e workload che aspettano servizi esterni

Web Functions modifica anche il modello economico. AWS misura separatamente CPU attiva e memoria occupata, mentre il tempo trascorso in attesa di una query al database, di una chiamata API o di un altro servizio downstream consuma poca CPU. È un modello particolarmente adatto a backend HTTP, server-side rendering e endpoint di inferenza AI in streaming, dove una parte significativa della vita della richiesta non consiste in calcolo continuo. Il cambio completa il precedente allargamento di Lambda verso workload più lunghi: se i 90 minuti avevano ridotto il confine temporale oltre il quale era necessario passare immediatamente a container o istanze, Web Functions riduce ora il confine applicativo. Non significa che ECS, Kubernetes o EC2 diventino superflui, ma restringe ulteriormente il gruppo di applicazioni per cui la gestione diretta dell’infrastruttura resta obbligatoria.

Multi-Region e canary deployment vengono incorporati nel servizio

AWS porta inoltre dentro Web Functions operazioni che normalmente richiedono diversi componenti infrastrutturali. Un’applicazione può essere distribuita in più Region con un singolo deployment e utilizzare un URL globale con routing basato sulla latenza, che tenta di servire ogni utente dalla Region più vicina. Le revisioni del codice sono snapshot immutabili e il traffico può essere suddiviso tra versioni differenti, consentendo rollout canary senza costruire un sistema esterno di bilanciamento. CloudFront può usare direttamente un Web Function endpoint come origin e proteggerlo attraverso Origin Access Control, mantenendo privato il backend dinamico. Questo avvicina Lambda non soltanto ai container gestiti, ma anche alle piattaforme specializzate nel deploy di applicazioni web: il valore non è più soltanto non amministrare server, ma non dover assemblare routing globale, scaling e rollout come servizi separati.

Il primo limite è Node.js e l’Europa parte soltanto dall’Irlanda

Al lancio il perimetro resta comunque definito. Web Functions supporta Node.js 24 su Arm64 ed è disponibile inizialmente in Virginia, Ohio, Oregon, Tokyo e Irlanda. L’Europa dispone quindi di una Region, eu-west-1, ma non ancora di una distribuzione estesa ai principali datacenter continentali AWS. Per workload soggetti a requisiti stringenti di localizzazione, resilienza geografica o architetture multi-Region esclusivamente europee, questa disponibilità iniziale può rappresentare un vincolo. Il supporto alla VPC consente invece di collegare direttamente le applicazioni a database e risorse private. Il contesto è coerente con la crescente industrializzazione dello stack AWS per AI e applicazioni distribuite, già evidente con Bedrock, AgentCore e SageMaker utilizzati come piattaforma enterprise per modelli e agenti.

Continua con:

AWS Lambda sale a 90 minuti e API Gateway porta i log fino a 1 MB

AWS rafforza API Gateway con mTLS e nuovi controlli backend

AWS sta cancellando il confine tra funzione e applicazione

Lambda Web Functions indica soprattutto una trasformazione del concetto di serverless. Il modello iniziale chiedeva agli sviluppatori di scomporre il software in funzioni brevi e adattarlo agli eventi della piattaforma; il modello del 2026 prova invece ad accettare l’applicazione così com’è e spostare sotto il servizio scaling, isolamento, routing e contabilizzazione delle risorse. AWS continua a mantenere distinzioni tra Event Functions, Web Functions e MicroVMs, ma l’obiettivo industriale è evidente: fare in modo che un numero crescente di workload possa restare dentro Lambda prima che l’architetto debba scegliere container o macchine virtuali. Il vero concorrente delle Web Functions non è quindi la vecchia Lambda. Sono tutte quelle piattaforme che hanno costruito la propria semplicità sul principio “porta il tuo framework e noi gestiamo l’infrastruttura”. AWS sta portando quella stessa promessa direttamente dentro il cuore del proprio serverless.