Cloudflare Workers o AWS Lambda: le differenze

Devi far girare del codice senza gestire un server, e le due strade più battute sono Cloudflare Workers e AWS Lambda. Sulla carta fanno la stessa cosa; nella pratica sono costruite su presupposti opposti, e sceglierne una senza saperlo significa scoprirlo a progetto avviato. In questo articolo trovi il confronto tecnico onesto, con una tabella e un verdetto per ogni tipo di caso d'uso.

La differenza di fondo

Lambda esegue il tuo codice in una regione che scegli tu, dentro una micro-VM isolata; Workers lo esegue su tutti i punti della rete Cloudflare, dentro un isolate V8 che condivide un processo già avviato.

Tutto il resto — cold start, prezzi, quali librerie funzionano, quanto pesa il pacchetto — discende da questa singola scelta architetturale. Se ti resta in mente solo una frase di questo articolo, sia questa.

Lambda parte dal presupposto che il codice possa essere qualsiasi cosa: un binario Go, un'applicazione Java, uno script Python con librerie compilate. Per farlo funzionare serve un ambiente completo, quindi serve avviarlo, quindi c'è un costo di avvio. Workers parte dal presupposto opposto: se accetti di scrivere JavaScript (o WebAssembly) e di usare le API della piattaforma web, l'ambiente è già acceso e l'avvio sparisce.

Dove gira il codice

Lambda gira in una regione. Scegli eu-central-1 o us-east-1 e il codice sta lì. Un utente australiano paga il viaggio fino in Europa a ogni richiesta.

Il vantaggio è che puoi mettere la funzione accanto ai dati. Se il tuo database sta in quella stessa regione, la query dura pochi millisecondi.

Workers gira ovunque. Il codice è replicato su tutti i punti di presenza della rete, e la richiesta viene servita dal più vicino. Nessuna regione da scegliere e nessun load balancing geografico da configurare: la logica di distribuzione la fa la rete, che è la stessa infrastruttura descritta in cos'è una CDN.

Il rovescio della medaglia è importante e viene spesso taciuto. Se il Worker deve interrogare un database centralizzato, essere vicino all'utente significa essere lontano dal database. Cinque query in sequenza da un punto di presenza dall'altra parte del mondo possono essere più lente della stessa funzione Lambda piazzata accanto ai dati. Workers vince sulla latenza solo se i dati sono vicini a lui, cioè su KV, D1, R2, oppure se non servono dati.

Cold start

Qui non c'è partita, e vale la pena capire perché.

Lambda deve preparare un ambiente. Micro-VM, runtime, dipendenze, poi il tuo codice. Con Node o Python su un pacchetto snello si parla di una manciata di centinaia di millisecondi; con Java o .NET e un pacchetto grosso si arriva tranquillamente ai secondi. AWS offre rimedi — la concorrenza pre-allocata, che tiene istanze già pronte, o runtime compilati leggeri — ma sono rimedi: costano soldi o vincoli.

Workers non prepara niente, perché il motore V8 è già in esecuzione. Deve solo creare un isolate e caricarci dentro il tuo codice. È talmente basso da non essere una variabile di progetto.

La differenza si sente soprattutto sul traffico irregolare: un endpoint chiamato dieci volte al giorno su Lambda è freddo praticamente sempre, e ogni utente paga l'avvio. Il quadro generale del fenomeno è in cosa sono le serverless functions.

Runtime e librerie: qui vince Lambda

Se il confronto precedente era a senso unico, questo lo è in direzione opposta.

Lambda esegue praticamente tutto. Node, Python, Java, Go, .NET, Ruby, e con i runtime personalizzati e le immagini container qualsiasi cosa tu riesca a impacchettare. Accesso al filesystem in una directory temporanea, processi figli, binari nativi, driver di database ufficiali, SDK completi. Se una libreria esiste, su Lambda gira.

Workers esegue JavaScript, TypeScript e WebAssembly, con le API della piattaforma web. Niente filesystem, niente processi, niente moduli nativi. Molti moduli Node sono emulati attivando i flag di compatibilità, ma è emulazione: copre i casi comuni, non tutti. Rust, Go e C++ arrivano solo compilati in WebAssembly, con le limitazioni del caso.

Questo si porta dietro anche i limiti di dimensione: il pacchetto di un Worker è piccolo, quello di una Lambda è largo, e con le immagini container diventa enorme. Se il tuo codice deve trascinarsi dietro un modello, un motore di rendering o un SDK monolitico, la conversazione finisce qui.

E c'è il tempo di esecuzione: Lambda accetta lavoro che dura minuti, i Workers sono tarati su lavoro breve — il tempo di attesa su una chiamata esterna non conta, il tempo di CPU sì. Se devi elaborare video, generare documenti pesanti o macinare dati, è Lambda. Il dettaglio dei limiti è in cosa sono i Cloudflare Workers.

Modello di prezzo

Niente cifre precise qui, perché cambiano spesso e invecchiano male. Quello che conta è la forma dei due modelli, che è diversa.

Lambda fattura su due assi: numero di invocazioni e durata moltiplicata per la memoria allocata. Se assegni più memoria paghi di più al millisecondo (ma ricevi anche più CPU, quindi a volte il lavoro finisce prima e spendi meno). E il conto della funzione è solo una parte: attorno c'è il resto di AWS — il gateway API, i log, il traffico in uscita, il NAT se la funzione sta in una rete privata. È la voce che sorprende chi legge solo il prezzo di Lambda.

Workers fattura sulle richieste e sul tempo di CPU effettivo, non sul tempo trascorso. Una funzione che attende due secondi una API esterna consuma pochissima CPU e costa poco, mentre la stessa attesa su Lambda la paghi tutta. In più il traffico in uscita non è la voce dolente che è su AWS, e su R2 è espressamente escluso.

In pratica: con lavoro leggero, molte richieste e molta attesa su chiamate esterne, Workers tende a costare meno e in modo più prevedibile. Con lavoro pesante e sporadico, la differenza si assottiglia e conta molto di più cosa c'è intorno. Entrambi hanno un piano gratuito serio, sufficiente a sviluppare e a reggere progetti piccoli.

Ecosistema

Lambda è un pezzo di AWS, ed è il suo argomento più forte. Si aggancia nativamente a S3, DynamoDB, SQS, EventBridge, Step Functions, RDS. Vuoi eseguire codice quando un file viene caricato, quando arriva un messaggio in coda, quando una tabella cambia? È già cablato. Per architetture complesse e orchestrazioni articolate non c'è confronto. Il prezzo è la complessità: IAM, VPC, ruoli e permessi sono una curva di apprendimento vera, e il legame con il fornitore è forte.

Workers è un pezzo di Cloudflare, con un ecosistema più piccolo ma coerente: KV, D1, R2, Queues, Durable Objects, Pages. Meno pezzi, molto più semplici da mettere insieme. Se stai già usando Cloudflare come scudo e acceleratore del sito, i Workers sono la naturale estensione programmabile di qualcosa che hai già davanti al traffico.

Sull'esperienza di sviluppo la sensazione è netta: wrangler dev e wrangler deploy sono due comandi e pochi secondi. Su Lambda serve quasi sempre uno strumento di infrastruttura come codice (SAM, CDK, Terraform, Serverless Framework) perché la funzione da sola non basta mai.

La tabella

	Cloudflare Workers	AWS Lambda
Dove gira	Su tutta la rete, vicino all'utente	Nella regione che scegli
Isolamento	Isolate V8 (processo condiviso)	Micro-VM dedicata
Cold start	Praticamente assente	Da centinaia di ms a secondi
Linguaggi	JS, TS, WebAssembly	Node, Python, Java, Go, .NET, Ruby, container
Filesystem	No	Sì, directory temporanea
Librerie native	No	Sì
Durata	Lavoro breve (CPU contata)	Fino a minuti
Dimensione pacchetto	Piccola	Grande, enorme con container
Costo	Richieste + CPU effettiva	Invocazioni + durata × memoria
Traffico in uscita	Non è la voce dolente	Può pesare parecchio
Vicinanza ai dati	Ottima con KV/D1/R2, scarsa con DB centrale	Ottima se il DB è nella stessa regione
Ecosistema	Piccolo e coerente	Vastissimo
Curva di apprendimento	Bassa	Alta (IAM, VPC, IaC)

Cosa fa perdere ore

Portare una Lambda su Workers senza controllare le dipendenze. Il codice sembra compatibile, poi in produzione salta fuori il pacchetto che importa fs o un driver nativo. Controlla prima le librerie, non dopo aver riscritto le rotte.

Mettere il Worker al bordo e il database in una sola regione. È l'errore concettuale più comune: ti aspetti latenza bassa e ottieni il contrario, perché ogni query attraversa mezzo mondo. Se il database è centralizzato, riduci i round trip a uno oppure valuta Lambda nella stessa regione dei dati.

Guardare solo il prezzo della funzione. Su Lambda il grosso del conto spesso non è Lambda: è il gateway, i log e il traffico in uscita. Fai il conto sull'architettura completa.

Fidarsi dei benchmark di cold start visti online. Sono quasi sempre "hello world". Il tuo cold start dipende dalle tue dipendenze e dal tuo runtime: misuralo sul tuo codice.

Ignorare la rete privata su Lambda. Metterla dentro una VPC per raggiungere un database privato aggiunge configurazione e, se serve uscire verso internet, un componente in più con il suo costo. Va previsto in partenza.

Il verdetto, caso per caso

Scegli Workers se: stai facendo autenticazione, redirect, riscritture, test A/B o personalizzazione al bordo; hai API leggere e frequenti; la latenza percepita è un requisito; il traffico è irregolare e i cold start ti stanno rovinando i tempi; sei già dentro Cloudflare; vuoi qualcosa di operativo in un pomeriggio.

Scegli Lambda se: ti serve un linguaggio che non sia JavaScript; dipendi da librerie native o SDK pesanti; il lavoro dura più di qualche istante; sei già su AWS e devi reagire a eventi di S3, code o database; ti serve orchestrazione complessa; il tuo database vive in una regione e le query sono tante.

Usali insieme se ha senso, ed è più comune di quanto sembri: Workers davanti come strato di ingresso — autenticazione, cache, instradamento, protezione — e Lambda dietro per il lavoro pesante. È lo stesso schema di Cloudflare più un reverse proxy: non sono alternative, sono strati diversi.

In sintesi

La differenza di fondo è architetturale: Lambda avvia una micro-VM in una regione, Workers crea un isolate su un motore già acceso, ovunque.

Workers vince su latenza e avvio. Cold start irrilevante, codice vicino all'utente, costi prevedibili sul lavoro leggero.

Lambda vince su ecosistema e potenza. Qualsiasi linguaggio, qualsiasi libreria, lavoro lungo, e mezzo AWS già collegato.

La domanda decisiva è dove stanno i tuoi dati e quanto dura il tuo lavoro. Dati distribuiti e lavoro breve → Workers. Dati in una regione e lavoro pesante → Lambda.

Per approfondire il funzionamento di uno dei due vedi cosa sono i Cloudflare Workers, e per il contesto generale cos'è il cloud computing.