Dove lo faccio girare? Lambda vs Fargate

Apri la console AWS, cerchi una casa per il tuo codice e ti trovi di fronte a una serie di opzioni: EC2, ECS, EKS, App Runner, Beanstalk, Lightsail…

La verità è che nel 90% dei casi moderni, la scelta si riduce a un duello tra due pesi massimi: AWS Lambda e AWS Fargate.

Eppure, a causa della confusione, ci sono ancora casi in cui Kubernetes (tramite EKS) viene usato per un semplice cronjob, oppure ci sono Lambda costrette a fare i lavori pesanti di un batch process, bruciando budget importanti in secondi.

Oggi risolviamo ogni dubbio e vediamo alcune regole pratiche per chi lavora con il cloud AWS ma vuole dormire sonni tranquilli.

Premessa tecnica: alcuni tutorial non sono aggiornati

Partiamo da un assunto: non è più il 2019.
Se stai scegliendo Fargate perché il codice ha troppe dipendenze, stai sbagliando approccio.

Dal 2020 Lambda supporta le Container Images (OCI) fino a 10GB. La pipeline CI/CD, il Dockerfile, i tool locali: tutto rimane identico.

La differenza oggi non è nel come pacchettizzi il codice, ma nel come quel codice viene eseguito sulla piattaforma.

Scegliere tra Lambda e Fargate significa scegliere tra due filosofie architetturali opposte.

Event-Driven vs Long-Running

AWS Lambda è “Reattiva” (Event-Driven)

È codice che dorme, non esiste un server acceso in attesa.

Lambda si sveglia solo in risposta a un evento (una chiamata API, un file su S3, un messaggio SQS), esegue e muore: è effimera.

Ideale per: “È successo qualcosa?”

AWS Fargate è “Continuo” (Long-Running)

Tu dici ad AWS: “Ecco il container, servimi 2 vCPU e 4GB di RAM”; AWS trova l’hardware, lancia il container e ti dà un IP.

Il container resta sempre su: quando non elabora, aspetta.

Ideale per: “Sto lavorando a un processo continuo”.

Ma quindi quale scelgo?

Se sei ancora indeciso/a, valuta questi 4 punti.

1. Tempo di esecuzione (15 minuti Hard Limit)

Questa è la regola ferrea, senza appello. Una funzione Lambda ha un timeout massimo di 15 minuti. Se il tuo processo dura 15 minuti e 1 secondo, Lambda lo ucciderà senza pietà.

• Task lungo o imprevedibile? -> Scegli Fargate.

• Task rapido e atomico? -> Scegli Lambda.

2. Il Pattern del Traffico: Esplosione vs Costanza

Qui la partita si gioca sulla performance.

• Lambda scala istantaneamente. Da 0 a 1.000 esecuzioni parallele in secondi. È perfetta per carichi “esplosivi” e imprevedibili (es. notifiche push, webhook).

• Fargate ha tempi di provisioning più lunghi (spesso 60-90 secondi per un nuovo task), ma una volta attivo azzera la latenza sulla singola richiesta.

Traffico costante 24/7? Fargate è più stabile e reattivo, su cui non hai la “penalty” dei cold start per ogni richiesta del portale aziendale usato costantemente.

3. Confronto tra Costi

Attenzione qui, perché parliamo di un aspetto apparentemente controinuitivo ma molto importante.

• Lambda: Paghi per richiesta + durata (millisecondo/GB). Se nessuno la chiama, paghi zero.

• Fargate: Paghi per vCPU/ora. Finché il container è acceso, il tassametro corre, anche se sta girando a vuoto.

Il paradosso: Se hai un servizio ad altissimo traffico costante, Lambda diventa incredibilmente costosa.

Come regola empirica: se il tuo carico di lavoro tiene la CPU impegnata per oltre il 60-70% del tempo, Fargate è quasi sempre più economico.

• Traffico intermittente/zero? -> Lambda.

• Alto volume continuativo? -> Fargate.

4. Il Costo Nascosto (Human Ops)

Spesso viene ignorato durante il calcolo del budget nei fogli Excel, ma impatta il team.

• Lambda (Zero Ops): Non gestisci networking, non gestisci load balancer, non gestisci cluster. È puro codice.

• Fargate (Low Ops): Devi configurare VPC, Subnets, Application Load Balancer, Target Groups e regole di auto-scaling. Richiede competenze DevOps più solide.

Hai un team piccolo focalizzato sul prodotto? Lambda vince, permette di muoversi più veloci.

Scenari Reali: Cosa scegliere quando?

Non basta la teoria, guardiamo la pratica sul campo.

Scenario A: Backend per App Mobile (Startup/Scale-up)

• Situazione: Traffico imprevedibile, picchi improvvisi, budget limitato.

• Scelta: Lambda. Paghi solo quando gli utenti usano l’app. Scala all’infinito durante i picchi senza configurare auto-scaling complessi. Zero costi fissi di notte.

Scenario B: Migrazione Monolite Legacy (Java/Spring)

• Situazione: Vecchia applicazione che impiega 45 secondi solo per avviarsi (boot time pesante).

• Scelta: Fargate. Non puoi costringere l’utente ad aspettare 45 secondi di cold start ogni volta che una Lambda si “sveglia”. Su Fargate il container è caldo e risponde in millisecondi.

Scenario C: Elaborazione Dati Notturna (Batch)

• Situazione: Job che genera report PDF complessi. Durata media: 30-40 minuti.

• Scelta: Fargate. Lambda andrebbe in timeout. Usa ECS Tasks schedulati: lancia il container, fa il lavoro, e si spegne alla fine.

La Matrice Decisionale (TL;DR)

Di seguito, una bussola per orientarti rapidamente:

Conclusione… per ora

Non esiste LA soluzione perfetta, la panacea a tutti i mali… Esiste però lo strumento giusto per il problema specifico.

Il mio consiglio?

1. Se stai costruendo qualcosa di nuovo, event-driven e stateless: parti da Lambda. È la via più veloce con zero gestione infrastrutturale.

2. Se stai migrando l’esistente, hai bisogno di controllo sui timeout o traffico pesante: parti da Fargate.

Tra l’altro, la bellezza del Cloud moderno è un’altra: l’invertibilità.

Nel prossimo articolo infatti parleremo di Infrastructure as Code (IaC).
Perché se hai architettato bene il tuo Terraform, spostare il workload da Lambda a Fargate richiede olo di cambiare poche righe di configurazione.

Così scegli bene oggi, ma mantieni la libertà di cambiare domani.