EC2, Lambda o Fargate? La scelta che sbagliano tutti

All’esame c’è sempre almeno una domanda così: “L’azienda vuole eseguire X. Cosa usi?”

E le risposte sono sempre più o meno le stesse: EC2, Lambda, Fargate, magari ECS in aggiunta. Sono i tre, quattro, se vogliamo essere precisi, servizi di compute fondamentali di AWS. Capire come scegliere tra loro salva almeno tre punti netti al Cloud Practitioner e cinque al SAA. Soprattutto, ti evita di costruire architetture che funzionano ma costano il doppio.

Il problema è che quasi tutti i corsi te li spiegano uno alla volta, come se fossero servizi indipendenti. Ed è qui che parte la confusione: Francesco impara EC2, poi Lambda, poi Fargate, e alla fine non sa come scegliere. Perché nessuno gli ha mostrato i tre fianco a fianco.

In questo articolo facciamo proprio questo. Un’analogia, tre profili a confronto, un framework decisionale in quattro domande. Senza giri di parole.

Immagina il menu del ristorante AWS. Sezione “compute”: una sola domanda da risolvere, come ed esattamente dove gira il mio codice?, e tre piatti diversi. EC2 è la pasta fatta in casa con il sugo che decidi tu, dall’ingrediente alla cottura. Fargate è la pasta del ristorante: ordini, te la portano, non vedi la cucina. Lambda è il piatto del distributore automatico in stazione: zero attesa, paghi solo quel singolo piatto, non puoi personalizzarlo. Stesso obiettivo (mangiare), tre prezzi, tre gradi di controllo.

O, se preferisci, immagina tre modi per attraversare una città.

EC2: l’auto a noleggio che guidi tu

EC2 (Elastic Compute Cloud) è il servizio compute più vecchio di AWS, e per molti versi quello che ha definito l’intera categoria. Lanciato nel 2006, è anche il primo che si incontra in qualunque corso introduttivo. Per una ragione: è il più immediato da capire per chi viene dal mondo on-premise.

Un’istanza EC2 è, letteralmente, una macchina virtuale. Tu scegli il tipo (t3.micro per esperimenti leggeri, m5.xlarge per workload più seri, c6i.4xlarge per uso CPU-intensive, e così via), scegli il sistema operativo (Amazon Linux, Ubuntu, Windows Server, Red Hat…), scegli la VPC e la subnet in cui collocarla, scegli lo storage allegato, scegli il Security Group che fa da firewall. Poi clicchi Launch e nel giro di un minuto hai una macchina raggiungibile via SSH (o RDP).

Pensala come un’auto a noleggio che guidi tu. La paghi a ore, decidi tu il modello, ci metti dentro quello che vuoi, scegli tu il percorso. Hai pieno controllo, e in cambio hai piena responsabilità: patching dell’OS, configurazione del firewall, gestione dei backup, monitoring delle metriche di sistema. Tutto tuo.

Questo è il punto chiave per l’esame. Su EC2, tu sei responsabile di tutto quello che sta sopra l’hypervisor. AWS gestisce solo l’hardware fisico, l’hypervisor, e la connettività di rete del data center. Il resto, kernel, runtime, librerie, applicazione, è affar tuo. È la definizione operativa del shared responsibility model nel suo punto più “client-heavy”.

EC2 brilla quando:

Hai un workload che gira in continuo, a piena potenza, 24 ore su 24. Auto Scaling con istanze on-demand, Reserved o Spot ti dà costi unitari più bassi di qualunque alternativa serverless.
Hai dipendenze di sistema operativo molto specifiche. Un kernel patchato, un driver custom, un binario legacy che gira solo su una certa versione di CentOS. Su EC2 ci sta. Su Lambda no, e su Fargate richiede acrobazie.
Devi orchestrare processi long-running. Un job di analisi che dura otto ore, un training di un modello ML che richiede una GPU dedicata, un server di gioco persistente. Lambda muore a 15 minuti, Fargate non è ottimizzato per quello, EC2 invece sta lì finché glielo dici tu.
Stai facendo un lift-and-shift da on-premise. La tua azienda ha una VM con un’app Java mostro? Su EC2 ce la riprodurci uguale. Niente refactor, niente rewrite. Funziona, e questo a volte è quello che serve.

Costo principale: il tempo durante il quale l’istanza è accesa. Anche se non sta facendo nulla, se è “running”, paghi. Questa è la prima trappola d’esame: una domanda che dice “workload molto intermittente, traffico imprevedibile, usato pochi minuti al giorno” e propone EC2 come opzione. Non è la risposta. Lambda lo è.

Fargate: l’auto con autista

Fargate è il servizio che meno persone capiscono al primo passaggio. Perché Fargate, in sé, non è un servizio “autonomo”: è una modalità di esecuzione per i due servizi container di AWS, ECS (Elastic Container Service) ed EKS (Elastic Kubernetes Service).

Quindi: ECS ed EKS sono gli orchestratori (ti dicono come e quando far girare i container). Fargate è il substrato di esecuzione serverless che fa girare quei container senza che tu debba gestire una flotta di EC2 sottostante. Esiste anche l’alternativa, far girare ECS o EKS sopra EC2 che gestisci tu, ma la maggior parte dei nuovi progetti sceglie Fargate per semplicità.

Pensalo come un’auto con autista. Hai una destinazione precisa (il tuo container, il tuo codice, la tua immagine Docker). Tu scegli dove andare e che bagagli portare. Ma non sei tu a guidare, non scegli la macchina, non fai il pieno, non ti occupi della manutenzione. Paghi la corsa, vieni portato dove devi andare, scendi.

La cosa interessante è il modello di pricing. Su Fargate paghi per la combinazione di vCPU e memoria allocate al tuo task, dal momento in cui parte fino a quando termina. Non c’è un’istanza sottostante che continua a costare quando il container è spento. Se hai un task che gira cinque minuti, paghi cinque minuti.

Quando Fargate è la risposta giusta:

Hai un’applicazione già containerizzata o vuoi containerizzarla. Lavori con Docker, hai un’immagine pronta, vuoi metterla in produzione senza gestire VM sottostanti. Fargate fa esattamente questo.
Il workload non è event-driven (cioè non parte da un trigger isolato come un upload su S3), ma è un servizio che deve essere sempre raggiungibile, una API, un worker, un microservizio.
Non vuoi gestire patching di OS, ma hai bisogno di girare codice che non sta dentro i limiti di Lambda (durata, runtime supportati, dimensione del pacchetto).
Stai facendo migrazione di un’architettura a microservizi e vuoi un’opzione in mezzo tra “Lambda per tutto” (che a volumi alti diventa caro) e “EC2 per tutto” (che ti obbliga a gestire OS e capacity).

Fargate è il middle ground che spesso viene dimenticato. È il piatto del menù che vince il confronto in tantissimi scenari reali, non sempre quello più sexy, ma quello che ottimizza meglio costo, semplicità e portabilità del codice.

Lambda: il taxi che prendi solo quando serve

Su Lambda c’è già un articolo dedicato in questo blog, Lambda spiegato come se avessi 5 anni, e ti consiglio di leggerlo prima o subito dopo questo. Qui basta una sintesi funzionale al confronto.

Lambda è il servizio compute dove non scegli nulla dell’infrastruttura. Non scegli istanza, non scegli OS, non scegli VPC (a meno che non ti serva esplicitamente). Scegli solo: il runtime (Python, Node, Java, Go, Ruby, .NET o un container Docker), la quantità di memoria allocata, il timeout massimo (fino a 15 minuti), e il trigger che la chiama. AWS si occupa di tutto il resto. Carica il codice, lo esegue, ti fattura solo i millisecondi consumati.

Pensalo come un taxi che chiami solo quando ti serve. Non hai l’auto parcheggiata sotto casa che paghi anche se non la usi, non hai l’autista in attesa. Apri l’app, arriva il taxi, ti porta dove devi andare, paghi la corsa. Zero costo se non lo prendi.

Lambda è la risposta quando:

Hai un trigger event-driven puro. Un file caricato su S3, un messaggio in coda, un cron schedulato, una chiamata HTTP via API Gateway.
Il traffico è imprevedibile o sporadico. Lambda scala da zero a migliaia di esecuzioni simultanee senza che tu faccia nulla, e a zero non paghi.
L’esecuzione è breve. Sotto i 15 minuti, idealmente sotto il minuto. La sweet spot di Lambda sono task che durano millisecondi o pochi secondi.
Vuoi minimizzare lo sforzo operativo. Niente patching, niente scaling, niente capacity planning. Solo codice.

Lambda non è la risposta quando:

Il workload è continuo a piena potenza. A volumi sostenuti, Fargate o EC2 con Auto Scaling sono drasticamente più economici.
L’esecuzione dura più di 15 minuti. Il timeout di Lambda è invalicabile.
Hai bisogno di stato persistente in memoria locale tra invocazioni.
Hai requisiti molto specifici di runtime, dipendenze di sistema o accesso a hardware speciale.

Questo è il punto dove il SAA fa la trappola classica. Domanda: “L’azienda vuole un servizio che processi un evento generato da S3, in modo asincrono, con scalabilità automatica”. Risposte: EC2, Fargate, Lambda, ECS. La risposta è Lambda, l’evento-driven puro è il suo habitat naturale. Ma se la domanda dice “workload computazionale che gira 24/7 con alto throughput”, la risposta diventa quasi sicuramente Fargate o EC2 con Auto Scaling. Lambda sembra plausibile, e qui Francesco perde il punto.

Il framework di scelta in 4 domande

Quando ti arriva una domanda d’esame (o una scelta architetturale reale), passa attraverso queste quattro domande, in ordine. Sono il modo più veloce per arrivare alla risposta senza memorizzare casi specifici.

1. Quanto dura una singola esecuzione? Se supera i 15 minuti, Lambda è fuori. Restano EC2 e Fargate. Se sta sotto i 15 minuti, soprattutto se sta sotto il minuto, Lambda è il candidato più forte, finché le altre tre domande non te lo contraddicono.

2. Il workload è event-driven o continuo? Se è event-driven (parte da un trigger, fa la sua cosa, finisce), Lambda è quasi sempre la risposta naturale. Se è continuo (un server HTTP che deve essere sempre raggiungibile, un worker che processa una coda 24/7 a saturazione), Lambda diventa cara, Fargate o EC2 sono più economici.

3. Hai container già pronti (o vuoi usarli)? Se sì, e il workload non è event-driven puro, Fargate è la scelta più semplice. Niente VM da gestire, ma compatibilità totale con Docker e con i tool dell’ecosistema container. Se hai già un’orchestrazione Kubernetes interna, EKS su Fargate è la versione managed.

4. Hai bisogno di controllo profondo del sistema operativo o di hardware specializzato? Se sì, GPU dedicate, kernel custom, driver specifici, dipendenze legacy, EC2 è l’unica opzione tra le tre. È anche l’opzione che ti dà più leve per ottimizzare i costi con Reserved Instances e Savings Plans, se il workload è prevedibile.

Le quattro domande in cascata danno la risposta nel 90% dei casi d’esame, e in una buona metà dei casi reali. Per il rimanente 10%, workload misti, requisiti regolatori, architetture ibride, entra in gioco il giudizio architetturale, e qui non ci sono regole, solo esperienza.

C’è un’ultima cosa che vale la pena dire. Spesso la risposta migliore non è uno solo dei tre. Un’architettura matura tende a usare tutti e tre nei loro punti di forza: EC2 per workload pesanti e prevedibili, Fargate per microservizi containerizzati, Lambda per tutto ciò che è event-driven, di breve durata e occasionale. Il SAA testa anche questo, la domanda combo in cui devi scegliere quale servizio per quale parte dell’architettura.

Domande frequenti su EC2, Lambda e Fargate

Qual è più economico tra i tre? Dipende dal pattern di utilizzo. Per traffico molto sporadico, Lambda vince per distacco perché non paghi nulla a riposo. Per traffico stabile e alto, EC2 con Reserved Instances o Savings Plans è quasi sempre il più economico, seguito da Fargate. La domanda giusta non è “qual è il più economico”, ma “qual è il più economico per questo specifico pattern di traffico”.

ECS e Fargate sono la stessa cosa? No. ECS è l’orchestratore (decide quando e dove far girare i container). Fargate è una modalità di esecuzione per ECS (e per EKS) che elimina la necessità di gestire EC2 sottostanti. Puoi usare ECS senza Fargate, in quel caso fai girare i container su EC2 che gestisci tu, modalità chiamata ECS on EC2.

Posso usare Lambda dentro una VPC? Sì, configurando la Lambda per girare in una VPC specifica. Serve quando la Lambda deve accedere a risorse private, un RDS, una ElastiCache, una EC2 interna. Tieni presente che Lambda in VPC ha un cold start leggermente più lungo e richiede un NAT Gateway se deve uscire verso internet.

Quando dovrei usare Fargate invece di Lambda? Quando il workload non è event-driven puro, quando hai bisogno di container, quando l’esecuzione può durare più di 15 minuti, o quando hai bisogno di un servizio sempre raggiungibile (es. un’API HTTP). Lambda è ottima per task brevi triggerati da eventi; Fargate è meglio per servizi continui containerizzati.

Quando dovrei usare EC2 invece di Fargate? Quando hai bisogno di controllo profondo del sistema operativo, quando hai workload molto stabili e ad alto throughput (dove le Reserved Instances battono Fargate sul costo), quando hai dipendenze hardware specifiche (GPU, networking custom), o quando stai facendo un lift-and-shift di un’applicazione legacy non containerizzata.

Esistono alternative al di fuori di questi tre? Sì. Per workload batch a lunga durata c’è AWS Batch. Per applicazioni completamente managed senza pensare neanche al container, c’è App Runner o Lightsail. Per workload Kubernetes c’è EKS (con o senza Fargate). Ma per il Cloud Practitioner e il SAA, i tre che contano davvero sono EC2, Lambda e Fargate (più ECS come orchestratore).

Posso passare da uno all’altro facilmente? Dipende dal punto di partenza. Da EC2 a Fargate, se l’app è già containerizzata, è una migrazione abbastanza pulita. Da Fargate a Lambda, o viceversa, richiede riscrivere parte dell’applicazione (il modello event-driven di Lambda è strutturalmente diverso da un servizio long-running). Da EC2 a Lambda è quasi sempre un rewrite. La scelta iniziale, quindi, conta.

EC2, Fargate e Lambda non sono tre prodotti in competizione. Sono tre punti su un continuum di controllo. A un estremo, EC2 ti dà tutte le leve e tutte le responsabilità. All’altro, Lambda ti dà zero leve sull’infrastruttura e zero responsabilità, solo il codice. Fargate sta esattamente in mezzo, ed è il motivo per cui spesso vince i confronti su scenari reali pur non venendo mai eletto “vincitore” da nessuno.

La scelta dipende sempre dalle quattro domande sopra. Quanto dura. Event-driven o continuo. Container o no. Quanto controllo dell’OS. Memorizza l’ordine, applicalo a ogni scenario d’esame, e la maggior parte delle domande “compute” diventano meccaniche.

Se stai preparando il Cloud Practitioner, EC2 e Lambda sono entrambi argomenti d’esame; Fargate è citato. Per consolidare la mappa dei servizi compute, il Cloud Practitioner Starter Kit include una sezione comparativa con casi d’uso e scenari simili a quelli d’esame. Zero euro, dieci minuti.

Se sei pronto a un percorso strutturato, il corso AWS Cloud Practitioner CLF-C02 in italiano affronta i servizi compute con la stessa logica di questo articolo, analogia, profilo di ogni servizio, framework di scelta, esempi d’esame.

E se stai puntando al SAA, dai un’occhiata anche all’articolo sulla preparazione al SAA-C03 in 60 giorni, la sezione sui domini di compute è dove si gioca una buona parte del punteggio.

EC2, Fargate, Lambda. Auto, auto con autista, taxi. Stessa città, tre prezzi, tre gradi di controllo. La scelta giusta non esiste in astratto, esiste solo in funzione del viaggio.

Ti è stato utile questo articolo? Condividilo con il collega che continua a proporre “facciamo tutto in EC2” anche per il microservizio che riceve dieci richieste al giorno, l’analogia dell’auto a noleggio gli farà cambiare idea in cinque minuti.