Per anni siamo rimasti intrappolati nella dicotomia del Cloud Computing: scegliere la semplicit\u00e0 del serverless con Lambda e Fargate, oppure accettare il peso operativo di gestire le istanze EC2 in autonomia. Entrambe le opzioni avevano il loro caso d\u2019uso, ma nessuna delle due era perfetta.<\/p>\n\n\n\n
Non conto pi\u00f9 le volte in cui, alle conferenze, abbiamo parlato di Lambda vs Container o di Lambda vs Kubernetes (sono stato anche co-speaker su quest’ultimo argomento).<\/p>\n\n\n\n
Queste frasi le abbiamo sentite in molti talk, e la conclusione era sempre il classico: “Devi conoscere il tuo workload e scegliere il mix di tecnologie che ti permetta di ottimizzare costi ed efficienza.”<\/p>\n\n\n\n
Alla fine del 2025, AWS ha cambiato le regole del gioco. Nel giro di pochi mesi sono stati annunciati Lambda Managed Instances, ECS Managed Instances e EKS Auto Mode.<\/p>\n\n\n\n
Non sono aggiornamenti marginali: rappresentano un cambio nel modo in cui \u00e8 possibile progettare i workload su AWS, tenendo conto dei costi.<\/p>\n\n\n\n
Dove eravamo? Siamo onesti: Lambda \u00e8 brillante per architetture event-driven, API con traffico imprevedibile e funzioni che vengono eseguite poche volte al giorno.<\/p>\n\n\n\n
Lambda scala a zero, quindi si paga solo per ci\u00f2 che si usa. Ma far girare la stessa funzione in modo continuativo, con volumi elevati, finisce per incidere pesantemente sui costi, a causa del modello di prezzo pay-as-you-go.<\/p>\n\n\n\n
Fargate ha problemi simili. Azzera completamente la gestione dei server, il che \u00e8 fantastico per i team che non vogliono preoccuparsi del capacity planning. Ma separarsi dal mondo server comporta un costo direttamente misurabile nella bolletta mensile: le stesse risorse (CPU e RAM) costano di pi\u00f9 rispetto alle controparti EC2 (soprattutto considerando ECS su EC2).<\/p>\n\n\n\n
D’altra parte, gestire le proprie istanze EC2 offre il pieno controllo e un’economia molto migliore per workload costanti. In pi\u00f9 \u00e8 possibile scegliere tipi di istanze specifiche e specializzate e applicare gli sconti delle Reserved Instance. <\/p>\n\n\n\n
Il compromesso? Il team \u00e8 responsabile della manutenzione delle AMI, del security patching, dell’autoscaling e di tutto l’overhead operativo che comporta la gestione di un’infrastruttura “tradizionale”. <\/p>\n\n\n\n
Il vero costo di EC2 self-managed non \u00e8 solo il prezzo dell’istanza: sono le ore di engineering spese in operazioni che potrebbero essere dedicate allo sviluppo di nuove feature.<\/strong><\/p>\n\n\n\n Molti di noi lo pensavano da anni: avremmo bisogno di qualcosa a met\u00e0 tra “fully serverless” e “gestisci tutto tu”.<\/p>\n\n\n\n La risposta \u00e8 arrivata in tre varianti poco prima e durante il re:Invent 2025:<\/p>\n\n\n\n Le Lambda Managed Instances consentono di eseguire funzioni Lambda su istanze EC2 interamente gestite da AWS. \u00c8 possibile scegliere tra diversi tipi di istanza, tra cui Graviton4, networking ad alta banda e calcolo GPU.<\/p>\n\n\n\n AWS gestisce provisioning, patching, scaling e lifecycle management.<\/p>\n\n\n\n Il modello di pricing \u00e8 interessante:<\/p>\n\n\n\n C’\u00e8 per\u00f2 una differenza architetturale: le Lambda standard elaborano una sola invocazione per ciascun ambiente di esecuzione, mentre le Istanze Gestite possono gestire pi\u00f9 invocazioni concorrenti nello stesso ambiente di esecuzione.<\/p>\n\n\n\n Questo modello a multi-concorrenza consente un migliore utilizzo delle istanze EC2 sottostanti, e poich\u00e9 l’ambiente di esecuzione rimane lo stesso, \u00e8 possibile ridurre i “cold start”.<\/p>\n\n\n\n Quello che rende ancora pi\u00f9 interessante questa implementazione \u00e8 la possibilit\u00e0 di applicare EC2 Savings Plans e Reserved Instances alla parte compute sottostante. <\/p>\n\n\n\n Un Compute Savings Plan triennale pu\u00f2 far risparmiare fino al 72% sul prezzo EC2 on-demand, ma occorre tenere presente che la management fee del 15% si calcola sul prezzo on-demand (non sul prezzo scontato). <\/p>\n\n\n\n Anche cos\u00ec, per workload ad alto volume, \u00e8 possibile risparmiare in modo significativo rispetto alle Lambda standard (vedremo i conti pi\u00f9 avanti).<\/p>\n\n\n\n C’\u00e8 un ma (come sempre): le Lambda Managed Instances scalano in base all’utilizzo della CPU, non al tasso di invocazione. Ad esempio, se il traffico dovesse pi\u00f9 che raddoppiare in 5 minuti, ci sar\u00e0 throttling delle richieste mentre AWS provvede ad aggiungere istanze per far scalare l\u2019ambiente.<\/p>\n\n\n\n Anche per le ECS Managed Instances, AWS effettua il provisioning e gestisce le istanze EC2, occupandosi di patching e scaling: occorre specificare solo i requisiti dei task (CPU, memoria, instance type).<\/p>\n\n\n\n Questa \u00e8 una differenza rispetto a Fargate, dove \u00e8 possibile scegliere solo l’architettura (Graviton o x86). Ce ne siamo accorti (con nostra sorpresa) durante un troubleshooting di problemi di prestazioni di un workload sensibile alla latenza.\u00a0<\/p>\n\n\n\n A volte il task era ultrarapido, altre volte invece andava a singhiozzo, rallentando l’intera pipeline. Questo era dovuto proprio alla differenza tra la cpu assegnata al task, che non poteva essere scelta. Dopo aver individuato il problema, siamo tornati al “classico” ECS su EC2 e non si sono pi\u00f9 verificati problemi di prestazioni.<\/p>\n\n\n\n Se avessimo avuto la possibilit\u00e0 di utilizzare le managed instances, avremmo trovato il giusto compromesso: pi\u00f9 semplice di ECS su EC2 self-managed, pi\u00f9 economico di Fargate e con accesso a hardware specializzato.<\/p>\n\n\n\n Il modello operativo \u00e8 simile alle Lambda Managed Instances, ma con alcune differenze:<\/p>\n\n\n\n Attenzione: Fargate esegue ogni task nella propria microVM isolata, il che \u00e8 ottimo per la sicurezza, mentre le ECS Managed Instances possono ospitare pi\u00f9 task, venendo meno all\u2019isolamento. Esiste l\u2019opzione \u201csingle-task mode\u201d per un isolamento pi\u00f9 stringente, ma ovviamente ci sar\u00e0 un maggiore utilizzo delle risorse.<\/p>\n\n\n\n Inoltre, questo tipo di deployment avrebbe evitato il caso “The Undead” di “Infrastrutture da Incubo” perch\u00e9 le immagini dei container vengono scaricate dal registry solo se non sono gi\u00e0 presenti nell’istanza, potenzialmente risparmiando $800 in costi di NAT Gateway.<\/p>\n\n\n\n Parlando dei costi, anche in questo tipo di deployment si applica una management fee aggiuntiva rispetto al costo delle istanze EC2.<\/p>\n\n\n\n EKS Auto Mode offre come sempre il control plane gestito, ma si spinge oltre. L’autoscaling della parte compute \u00e8 gestito tramite Karpenter, il tool open-source che ottimizza l’utilizzo dei nodi e i costi. Gestisce anche il networking dei pod con la network policy enforcement, l’integrazione con il load-balancing e lo storage EBS CSI.<\/p>\n\n\n\n EKS Auto Mode offre:<\/p>\n\n\n\n L’impatto pratico \u00e8 significativo. Chiunque abbia gestito Kubernetes in produzione conosce i suoi punti dolenti: nodi bloccati in stato NotReady, esaurimento degli indirizzi IP a causa di configurazioni VPC CNI errate, upgrade falliti, il ciclo infinito di patching e di aggiornamento delle AMI.<\/p>\n\n\n\n EKS Auto Mode elimina la maggior parte di questi oneri operativi ricorrenti. Occorre per\u00f2 tenere presente che non si tratta di magia: il workload deve essere compatibile con questa modalit\u00e0 e richiede l\u2019implementazione di check adeguati per la readiness e la definizione di una pod eviction policy che risponda ai requisiti di business; altrimenti si otterranno solo downtime, singhiozzi e altri problemi quando Karpenter ottimizza la distribuzione dei pod per mantenere i costi bassi.<\/p>\n\n\n\n Anche con EKS Auto Mode \u00e8 prevista una management fee.<\/p>\n\n\n\n Proprio mentre stavamo ancora digerendo le managed instances, AWS ha introdotto anche le Lambda Durable Functions.<\/p>\n\n\n\n Questa feature consente alle funzioni Lambda di eseguire workflow che durano fino a un anno, utilizzando checkpoint e replay automatici per gestire fallimenti e attese.<\/p>\n\n\n\n Le Lambda Durable Functions adottano un approccio code-first: la logica del workflow \u00e8 scritta in Node.js o Python (attualmente solo questi due runtime gestiti sono supportati), e il Durable Execution SDK fornisce le primitive per il checkpointing e la pausa dell’esecuzione.<\/p>\n\n\n\n A questo indirizzo<\/a> \u00e8 presente un esempio di durable function.<\/p>\n\n\n\n Lambda Durable Function salva automaticamente un checkpoint quando l’esecuzione viene messa in pausa; quando riprende, il codice parte dall’inizio, ma salta i checkpoint gi\u00e0 completati, utilizzando i risultati salvati anzich\u00e9 eseguire di nuovo tutte le operazioni.<\/p>\n\n\n\n Con le durable functions, il costo \u00e8 dovuto al compute time e al numero di richieste, come al solito, ma non ci sono addebiti durante i periodi di attesa: un workflow pu\u00f2 girare per 1 minuto e attendere per 24 ore; verr\u00e0 fatturato solo 1 minuto.<\/p>\n\n\n\n Le durable operation (come avviare esecuzioni, completare step e creare attese) hanno per\u00f2 un costo aggiuntivo, come anche la quantit\u00e0 di dati scritti da queste operazioni (in GB) e la data retention durante e dopo l’esecuzione (in GB\/month). Il periodo di retention dopo il completamento \u00e8 configurabile da 1 a 90 giorni (il default \u00e8 14 giorni).<\/p>\n\n\n\n Quando ho visto l’annuncio, ho chiesto ai miei colleghi del team Cloud Native Development: “Le Durable Functions sostituiscono le Step Functions?”<\/p>\n\n\n\n La risposta \u00e8 sfumata, perch\u00e9, anche se sembrano sovrapporsi funzionalmente, il loro utilizzo dipende da preferenze di sviluppo e dai pattern architetturali utilizzati.<\/p>\n\n\n\n Le Step Functions usano un approccio “configuration first”: definiscono i workflow in Amazon States Language (ASL), un DSL basato su JSON che coordina i servizi AWS con una minima quantit\u00e0 di codice. \u00c8 possibile usare un visual workflow designer per visualizzare l’intera state machine a colpo d’occhio.<\/p>\n\n\n\n Le Step Function si integrano con i servizi AWS senza richiedere codice custom. Per esempio, \u00e8 possibile avviare una Step Function quando un Amazon S3 Bucket viene reso pubblico, per notificare il team di sicurezza, che pu\u00f2 effettuare una review. Nel frattempo, la funzione aspetta un’approvazione manuale per la remediation. Quando l’approvazione manuale viene ricevuta o rifiutata, vengono intraprese le azioni necessarie (ad esempio rendere il bucket privato o applicare un tag che escluda il bucket da un controllo futuro).<\/p>\n\n\n\n Con Step function non ci sono nemmeno restrizioni di runtime: mentre le Durable Functions supportano solo Python 3.13 e 3.14 e Node.js 22.x e 24.x, le Step Functions possono avviare Lambda con runtime custom, avviare task ECS, eseguire Glue job e molto altro.<\/p>\n\n\n\n Parlando di costi: gli standard workflow addebitano $25 per milione di state transition; gli Express Workflow addebitano un costo in base alla durata e al numero di esecuzioni.<\/p>\n\n\n\nL’anello mancante tra due mondi<\/h2>\n\n\n\n
Lambda Managed Instances<\/h4>\n\n\n\n
\n
ECS Managed Instances<\/h4>\n\n\n\n
\n
EKS Auto Mode<\/h4>\n\n\n\n
\n
Altre opzioni: Lambda Durable Functions<\/h2>\n\n\n\n