AWS Lambda esegue server Node.js senza adapter, ma solo in un runtime

Il 12 ottobre 2026 AWS ha annunciato Lambda Web Functions: la nuova modalità esegue server HTTP senza adapter, gestisce fino a 128 richieste concorrenti per ambiente e, al lancio, offre il solo runtime Node.js 24 su Arm64; tra le regioni di disponibilità iniziale c’è Europa (Irlanda). Un’applicazione web può così arrivare su Lambda conservando il proprio modello di richieste HTTP.

Per un server Node.js esistente, route e middleware possono restare quelli dell’applicazione: non occorre riscriverli come handler che ricevono eventi Lambda. La compatibilità richiede però che il server ascolti sull’indirizzo assegnato dal servizio e che codice e dipendenze funzionino nel runtime disponibile. La concorrenza cambia anche il conto economico: l’attesa di un database usa poca CPU, mentre la memoria dell’ambiente continua a essere fatturata.

Che cosa resta del server Node.js esistente

Express, Hono e Fastify possono avviare il loro normale server HTTP dentro una Web Function. Lambda inoltra le richieste a quel processo, che continua a gestire percorsi, middleware e risposte secondo le regole del framework. Anche un’applicazione con rendering sul server o risposte in streaming può mantenere questa struttura, purché il suo server sia compatibile con l’ambiente di esecuzione.

La modifica di configurazione più concreta riguarda AWS_LAMBDA_HTTP_ENDPOINT, la variabile che contiene host e porta su cui il processo deve mettersi in ascolto. Un’applicazione che usa un indirizzo fisso deve leggerla all’avvio; alcuni framework possono richiedere un piccolo file d’ingresso che imposti le loro variabili prima di avviare il server. L’assenza di un adapter elimina la conversione tra evento Lambda e richiesta HTTP, ma non questa configurazione.

Aidan Steele scrive nel resoconto del suo test «There's no handler and no JSON event» e descrive un ambiente con 2 vCPU e 2 GB di memoria. La piattaforma pubblica una revisione immutabile del codice e la collega a un endpoint HTTPS; l’endpoint può poi indirizzare il traffico verso una revisione successiva. Per le applicazioni con moduli nativi, il vincolo Arm64 richiede inoltre pacchetti compilati per quell’architettura.

Più richieste condividono l’ambiente, non la fattura

In una Web Function il ciclo di eventi di Node.js può servire un’altra richiesta mentre la prima aspetta un database o un’API esterna. È una differenza sostanziale rispetto al modello standard delle Event Functions, nel quale un ambiente elabora una sola invocazione alla volta. Il limite massimo di concorrenza indica quante richieste possono condividere un ambiente, non quante ogni applicazione riuscirà a elaborare con la stessa latenza.

La documentazione AWS sulle Web Functions distingue richieste, tempo di CPU attiva, memoria consumata durante la vita dell’ambiente e trasferimento dati come voci di fatturazione. Se il server aspetta una risposta esterna, la componente CPU può scendere; la memoria continua invece a maturare un costo finché l’ambiente esiste, anche negli intervalli inattivi tra richieste. Quando il traffico cessa, Lambda può rimuovere gli ambienti inattivi e scalare fino a zero.

Il vantaggio dipende quindi dal lavoro svolto, non dalla sola presenza di richieste concorrenti. Operazioni sincrone che occupano intensamente la CPU bloccano il ciclo di eventi e ritardano anche le altre richieste nello stesso processo; richieste simultanee consumano inoltre memoria nello stesso ambiente. Per un’API che trascorre molto tempo in attesa I/O, CPU attiva e memoria possono muoversi in direzioni diverse: una spesa CPU minore non implica che l’attesa sia gratuita.

Web Functions, Event Functions e MicroVM nella stessa architettura

L’endpoint di una Web Function fornisce HTTPS e può richiedere autenticazione IAM oppure lasciare l’autenticazione all’applicazione. Nel secondo caso Lambda inoltra le richieste senza autenticarle: è il codice del servizio a decidere chi può accedere. Per presentare un dominio personalizzato o aggiungere AWS WAF si colloca Amazon CloudFront davanti all’endpoint; il controllo dell’accesso all’origine può far firmare a CloudFront le richieste dirette a un endpoint protetto da IAM.

Una Web Function può anche essere distribuita in più regioni dietro un unico indirizzo globale, con instradamento basato sulla latenza. Questa possibilità riguarda la posizione in cui vengono servite le richieste, mentre la scelta fra le forme di Lambda riguarda soprattutto che cosa avvia il lavoro e come vive l’ambiente. Per un’applicazione destinata all’Italia, la disponibilità in Irlanda offre una regione europea iniziale, senza rendere automaticamente multiregionale una distribuzione configurata in una sola regione.

• Web Functions: accettano traffico HTTP direttamente da un server nel runtime gestito Node.js disponibile al lancio. Più richieste condividono il processo; si pagano richieste, CPU attiva, memoria e dati trasferiti. L’endpoint offre IAM o autenticazione applicativa, mentre un dominio personalizzato passa da CloudFront. Sono adatte ad API, applicazioni con rendering sul server e risposte in streaming che devono conservare route e middleware HTTP.
• Event Functions: eseguono un handler invocato da eventi e dispongono di una gamma più ampia di runtime. Nel modello standard ogni ambiente tratta una singola invocazione e la durata fatturata comprende anche il tempo di attesa. Code, caricamenti di file e altri eventi AWS sono carichi tipici; se la funzione deve rispondere sul web, autenticazione e dominio dipendono dall’ingresso scelto, per esempio un Function URL o API Gateway.
• MicroVM: offrono un ambiente isolato e con stato, il cui ciclo di vita è gestito dal cliente. Sono pensate per sessioni dedicate che eseguono codice di utenti o codice non attendibile, anziché per pubblicare un normale server HTTP condiviso. Ogni ambiente ha un endpoint dedicato con accesso tramite token; il costo va valutato in base all’istanza e alla durata della sessione, insieme alle altre componenti previste dalla configurazione. Un dominio comune per gli utenti richiede un livello d’ingresso progettato davanti a quegli endpoint.

Le tre forme possono convivere nello stesso prodotto: il server HTTP può rispondere tramite Web Functions, un handler può elaborare messaggi di coda con Event Functions e una MicroVM può mantenere lo stato di una sessione isolata. Per un’app Node.js già pronta, la migrazione del livello web riguarda soprattutto l’indirizzo di ascolto, le dipendenze Arm64 e il comportamento delle richieste che ora condividono lo stesso processo.

Leggi anche:

• AWS Cloud Practitioner o AZ-900: la lingua italiana può decidere la scelta
• OpenAI pubblica 722 lavori matematici: Lean ne verifica solo una parte
• Gli sviluppatori usano l’IA, ma solo il 6,6% le affida decisioni importanti